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(57) Abstract 

An apparatus (14) for controiling and providing force feed- 
back using an interface device manipulated by a user and connected 
to a host computer system (12). A microprocessor (26) is provided 
local to the interface device and reads sensor dau from senson that 
describes the positioning of a user object moved by the user, such 
as a joystick. The microprocessor controls actuators (30) to pro- 
vide forces on the user object. The host computer sends high level 
host commands to the local microprocessor and the microprocessor 
independently implements a local reflex process based on the high 
level command to provide force >-;ucs to actuators using sensor 
data and other parameters. A host command protocol mcludes a 
variety of different types of host commands and associated com- 
mand parameters. By providing a relatively small set of high level 
host commands, the protocol further shifts the computauonal bur- 
den from Ae host computer to the local microprocessor. 
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MFTHon AND APPARATUS_FQR 

( (iiiTrriTTTrTr rnirrr r'-^^^^^'^ imtfrface systems 

TTTIT I7TNG A H^RT rOMPUTER 

p^rKr.ffOUND ART 

The present invention relates generally to interface devices between humans and 
computers, and more pan.cularly to computer interface devices that provide force feedback to the 
user. 

computer systems are used extensively in many different industnes to implement 
computer controlled simulations, games, and other application programs. More particularly, these 
types of games and simulations are very popular with the mass market of home consumers. A 
computer system typically displays a visual environment to a user on a display screen or other 
visual output device. Users can interact with the displayed environment to play a game, 
expenence a simulation or ' virtual reality" environment, or otherwise inOuence events or images 
depicted on the screen. Such user interaction can be implemented through the use of a human- 
computer interface device, such as a joystick, "joypad" button controller, mouse, trackball, stylus 
and tablet or the like, that is connected to the computer system controlling the displayed 
environment. The computer updates the simulation or game in response to the users 
manipulation of an object such as a joystick handle or mouse, and provides feedback to the user 
utilizing the display screen and, typically, audio speakers. 

In some interface devices, tacule ("haptic") feedback is also provided to the user, more 
generally known as "force feedback." These types of interface devices can provide physical 
sensations to the user manipulating the object of the interface device. Typically, motors or other 
acmators are coupled to the object and are connected to the controlling computer system. TTie 
computer system can provide forces on the object in conjunction with simulation/game events by 
sending control signals to the actuators. The computer system can th-s convey physical 
sensations to the user in conjunaion with other supplied feedback as the user is gra.spmg or 
contacting the object of the interface device. Force feedback interface devices can thus provide a 
whole new modality for human-computer interaction. 

Force feedback input/output (1/0) devices of the prior art have concentrated on providing 
maximum haptic fidelity, i.e.. the realism of the tactile feedback was desired to be optimized. This 
is because most of the force feedback devices have been targeted at the specific needs of highly 
industrial applications, and not a mass consumer market. To attain such realism, mass market 
design concerns such as low size and weight, low complexity, programming compatibility, low 
cost, and safety have been sacrificed in the prior art. As a result, typical force feedback interface 
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devices include complex robotic mechanisms which require precision components and cxpcnsiNx 
actuators. 

An important concern for a force feedback interface device is communication bandwidth 
between the controlling computer and the interface device. To provide realistic force feedback, the 
5 complex devices of the prior art typically use high speed communication electronics that allow the 
controlling computer to quickly update force feedback signals to the interface device. The more 
quickly the controlling computer can send and receive signals to and from the interface device, the 
more accurately and realistically the desired forces can be applied on the interface object. In 
addition, using a high bandwidth communication interface, force feedback can be accurately 
10 coordinated with other supplied feedback, .such as images on the video screen, and with user 
inputs such as movement of the object, activated buttons, etc. For example, a user can grasp and 
move a force feedback joystick in a simulation to control an image of a car to drive over a virtual 
bumpy surface displayed on a screen. The controlling computer should provide control signals to 
the actuators of the joystick quickly enough so that the surface feels as realistically bumpy as the 
15 designer of the simulation intended. If the control signals are too slow, a realisuc feeling of 
bumpiness is more difficult to provide. Also, the cont«)lling computer needs a high bandwidth 
communication interface to accurately coordinate the supplied forees with the visual feedback on 
the screen, such as the moment on the screen when the car first contacts the bumpy surface. This 
high speed is likewise needed to accurately coordinate supplied forces with any input from the 
20 user, for example, to steer the car in particular directions. 

A problem is evident when prior an force feedback interface devices are provided to the 
mass consumer market. Most home computers have a built-in standard senal communication 
interfaces, such as an RS-232 or RS-422 interface, that may conveniently be used to connect 
peripherals like a force feedback interface device to the host computer. In addition, manufacturers 
25 prefer to provide peripheral devices that use these serial interfaces, since no additional hardware, 
such as interface cards, needs to be provided with such peripherals. Tht manufacturing cost of the 
peripheral device can thus be significntly reduced. However, these standard serial 
communication interfaces are typically quite slow (i.e. have low bandwidth) companid to other 
communication interfaces. Realistic and accurate force feedback thus becomes difficult to provide 

30 by a controlling computer system to a prior art interface device connected through such a senal 
interface. For example, U.S. Patent 5,184.319, by J. Kramer, describes a force feedback device 
that applies forces to a user's body parts. However, the Kramer device is typical of the prior art in 
that the host computer directly controls the actuators and directly receives the sensor data from the 
interface apparatus. Such a device is not suitable for a low bandwidth communication interface to 

35 achieve realistic force feedback. 
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Another problem with using prior art force feedback interface devices in the mass 
consumer market is the wide variety of computer platforms and processing speeds thai are used 
on different computers and on the same computer at different times. The force sensations 
provided to a user by a force feedback interface device may feel different to a user on different 
5 computer platforms or microprocessors, since these different computers run at different speeds. 
For example, the force feedback controlled by a 100 MHz computer may be much different from 
the force feedback controlled by a 60 MHz computer due to the different rates of processing 
control signals, even though these forces are intended to feel the same. In addition, the effective 
processing speed of one microprocessor can vary over time to provide inconsistent forces over 
10 multiple user sessions. For example, multitasking can vary or delay a microprocessors 
management of force feedback conu-ol signals depending on other programs that are running on 
the microprocessor. 

In addition, there is no standardized language or communication protocol for 
communicating with force feedback devices. A software developer that wishes to provide force 
15 feedback to an interface in a software application must currently set up his or her own specialized 
commands and/or communications protocols and must implement the force feedback controlling 
instructions at a low level. This requires unnecessary time and expense in the development of 
software applications that include features directed toward force feedback interfaces. 

Therefore, a more realistic and cost effective alternative to force feedback interfaces and 
20 force feedback control paradigms is desired for certain applications. 
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PVMflAPY T'"^- INVENTION 

The present invention is directed to controlling and providing force feedback to a user 
operating a human/computer interface device. Ue interface device is connected to a controUmg 
h^st computer and includes a separate microprocessor local to the interface device. The loca^ 
microprocessor allows high-speed control of forces to the interface device, thus ~g the 
realism and accuracy of provided forces over a slow communication interface w.th the host 
computer. 

More particularly, a system and method of the present invention for controlling an 
interface apparatus manipulated by a user includes a host computer system for receiving an mput 
control signal and for providing a host output control signal. Hie host computer updates a hos 
application process, such as a simulation or video game process, in response to the mput control 
signal. A microprocessor local to the interface apparatus and separate from the host computer 
receives the host output control signal and provides a processor output control signal. An acmator 
receives the processor output control signal and provides a force along a degree of freedom to a 
user-manipulated object coupled to the acmator in accordance with .he processor output control 
signal A sensor detects motion of the object along the degree of freedom and outputs the mput 
control signal including information representative of the position and motion of sa.d object. 
Preferably, the sensor outputs the input control signal to the local processor, which outputs the 
input control signal to the host computer. The user object is preferably grasped and moved by the 
user in one or more degrees of freedom, and can include such articles as a joystick, mouse. 
. simulated medical instrument, stylus, or other object. 

In one host-controlled embodiment, the host computer receives sensor information in the 
input control signal and determines the values of the forces. The hos. output control signal thus .s 
the deter^ned direct force command that is relayed through the microprocessor directly to the 
acmator. In a second, "renex" embodiment, the host computer receives the sensor ,nformat>on m 
a supervisory mode and outputs a high level force command to the m.croprocessor whenever a 
force is required to be applied to the user object or changed. In accordance with the high level host 
command, the microprocessor reads sensor and timing data and outputs low level force 
commands to the acmator according to a selected reflex process, m reflex process can mdude 
, using force equations, readmg force profiles of predetermined force values from a storage dev.ce. 
or other steps, and may be dependent on sensor data, timmg data, host command data, or otfier 
data The processor thus implements a "reflex" to control forces independently of the host 
computer until the host computer changes the type of force applied to the user object. 
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A«.gnitade of tlK force provided by *e actuator is dctemuned by ho« comparer or 
.he kcal „,c,op«cess»r. TTris magninrde ca. b< derer^ined from panme... .nclu .ng Jk 
po«doo »k«:i.y. ^ *e accctodon of .be object in panicular degrees of freedom, artd ..nuog 
li^r^lcto*. -n^forcec^tthus simulate diff«ent types of forces such as aspnng force, 
damping force, or inertia force. 

•n,c application process updated by U.c host computer system preferably includes 
application software that can be simulation software, game software, scientific software, etc. The 
host computer system displays images on a visual output device such as a display screen ^ 
synchronises the images and visual events with the position and mot.on mput ^rom ^ J^^ 
lipulatingtheobjectaswell asforces applied to theobject. The host co^^^^^^^^ 

synchronizes the timing and magnitude of audio feedback wUh force feedback The pre en 
invention can use a standard serial interface included on many computers to interface the host 
computer system with the local microprocessor. Alternatively, a parallel interface can be used, or 
a serial interface used in conjunction with a different interface on the host computer such as a 
game port. A clock is preferably coupled to the host computer system or the local processor 
which can be accessed to determine, in part, the force output by the actuator. 

The invention also provides a paradigm for force commands between the host computer and 
the local microprocessor. The h,gh level host commands provided by the host computer can be r.te 
control and/or position control commands, and may include information in the form of command 
parameters. By providing a relatively small set of commands and command parameters wh.ch are 
translated into a panoply of forces, the paradigm further shifts the computat.onal burden from the 
host computer to the local microprocessor. Host commands may mclude commands to prov.de 
forces on the user object such as restoring forces, vibration forces, texture forces, a barrier forces 
attractive/repulsive force fields, damping forces, groove forces, and a paddle-ball force. Typical 
eommand parameters include a magnitude parameter, a duration parameter, a direction parameter, a 
style parameter, and a button parameter to control the force output by the actuator. This provides 
high level, standard force feedback command protocol for the efficient use by developers of force 
feedback software to be implemented on the host computer system. 

A preferred implementation of the functionality of the local microprocessor is also 
provided. A command process receives a host command from the host computer and processes 
the host command and any included command parameters. Force parameters are derived from 
the host command and the parameters and are stored in memory. Preferably, every host 
command has a set of force parameters associated with it to be updated when the appropnate host 
command is received. A status update process reads sensor data from the sensors describing a 
, motion of the user object and can also compute velocity, acceleration, or other time-related values 
if appropriate. A force output process computes a force value using a reflex process selected m 
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accordance with the force parameters and the sensor data. In some instances, the force value may 
depend on the values of the force parameters and sensor data. The force output process outputs a 
force on the user object by sending the computed force value to the acmators. In adduton. a 
reporting process reports the sensor data to the host computer system when appropriate. 
Preferably, a plurality of host commands can be in effect simultaneously, where a force value .s 
summed from a reflex process correspondmg to each such host command in effect. Also 
parameter page(s) of sets of parameters can conveniently be stored in memory to allow different 
force environments to be selected. 

The control system and method of the present invention advantageously includes a 
separate microprocessor local to the interface device that is separate from the host computer 
system The local microprocessor can read and process sensor signals as well as output force 
command signals independently of the host computer, thus saving significant process.ng time on 
the host computer. In addition, the use of the local processor to handle low-level force feedback 
commands allows more nralistic and accurate force feedback to be provided to an object 
manipulated by a user when using a serial or other relatively low-bandwidth communication 
interface between the host and the interface device, since such low level force signals do not have 
to be transmitted over the communication interface. The use of a clock when generating force 
feedback commands in view of absolute timing information allows force sensations to be 
consistently experienced by users across different host computer platforms and at different 
sess.ons on the same host computer. The use of specific, high level host commands to command 
a variety of types of forces allows force feedback host applications to be easily created. These 
improvements allow a computer system to provide accurate and realistic force feedback over a 
low-cost, low bandwidth communication interface and is thus ideal for the mass market of home 
computer systems. 

These and other advantages of the present invention will become apparent to those skilled 
in the art upon a readmg of the following specification of the invention and a study of the several 
figures of the drawing. 
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BRIEF PFSCRy n^^N OF THF DRAWINGS 



Figure 1 is a block diagram of a control system in accordance with the present invention 
for controlling a force feedback interface device from a host computer. 
5 Figure 2 is a schematic diagram of an actuator interface for providing control signals to an 

active acmator for the present invention; 

Figure 3 is a schematic diagram of an acwator interface for providing control signals to a 
passive actuator for the present invention; 

Figure 4 is a flow diagram illustrating a first embodiment of a method of the present 
10 invention for controlling a force feedback interface device; 

Figure 5 is a flow diagram illustrating a second embodimem of a method of the presem 
invention for controlling a force feedback interface device; 

Figure 6 is a schematic diagram of a closed loop five bar linkage mechanism for providing 
two degrees of freedom to the user object of the interface device; 
,5 Figure 7 is a perspective view of a preferred embodiment of the linkage mechanism 

shown in Figure 6; 

Figure 8 is a perspective view of a slotted yoke joystick embodiment of a mechanical 
interface for the user object; 

Figure 9 is a table summarizing rate control commands of the present invention; 
20 Figures lOa-c are diagrammatic representations of restoring force profiles; 

Figures 1 la-c are diagrammatic representations of restoring spring force profiles; 
Figure 1 2 is a diagrammatic representation of a vector force; 
Figures 13a-b are diagrammatic representations of vibration force profiles; 
Figure 14 is a table summarizing position control commands of the present invention; 
25 Figure 1 5 is a diagrammatic representation of a groove force profile; 
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Figure 16 is a diagrammatic represenution of a barrier force profile; 

Figures 17a-17i are diagrammatic illustrations of a paddle and ball interaction controlled by a 
paddle command of the present invention; 

Figure 18 is a block diagram illustrating an implementation of the local microprocessor of the 
presem invention for controlling a force feedback interface device with host commands containing 
force parameters; 

Figure 19 is a flow diagram illustrating a host communication background process of Figure 

18; 

Figure 20 is a flow diagram illustrating a command process of Figure 1 8; 

Figure Zlis a flow diagram illustrating a reporting process of Figure 18; 

Figure 22 is a flow diagram illustrating force algorithm computation and actuator control 
process of Figure 18; and 

Figure 23 is a diagrammatic representation of force parameters and a sequence of force 
commands as used in the present invention. 
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««T MnnR_.i FOR r^B HYlMd o<T INVFNTION 

Fiiur. 1 U 3 block d,agn,n, illus^Uns a generic cooTol sysKm 10 of fl« present 
invcmionTor ^ interface device con-^lW by > -.OS. compu«r s,s«„,. Conm,. sys.en, 10 
includes a host computer system 12 and an interface device 14. 

Host computer system 12 is preferably a personal computer, such as an IBM«mpa,« 
or Macintosh personal computer, or a workstation, such as a SUN or Stitcon Graphtcs 
example, .e host compute, system can a persona, computer wht. ^ 
under the MS-DOS or Windows opetat.ng systems in conformance wtth an IBM PC AT 

Alternatively, host computer system 12 can t. one of a variety of home vt^o 
systems commonly connected to a television set, such as systems available from 
or Sony. In other embodiments, home computer system 12 can be a "set top box whtch can be 
used, for example, to provide interactive television functions to users. 

in the described embodiment, host computer system 12 implements a host applicatton 
program vrith which a user 22 is interacting via periphemis and intetface device 1 4. Fo, examp e^ 
L^t application program can be a video game, medical stmulat.on 
program, or even an operadng system or other application program to uuh.es force feedback. 
Ucally. the host application provides images to be displayed on a display output devtce. as 
described below, and/or other feedback, such as auditory signals. 

Host computer system 12 preferably includes a host microprocessor 16. random access 
memo^ (RAM, 17. read-only memory (ROM) .9, a Cock 18. a display screen 20. and an aud» 
output device 21. Host microprocessor 16 can include a variety of available microprocessors 
from Intel, Motorola, or other manufaourers. Microprocessor 16 can be single 
chip, or can include multiple primary and^or co-p«>cessors. Microprocessor 
Jstores instructions and other necessary dau from RAM 17 and ROM 19, as ,s well known to 
those skilled in the an. In the described embodimem. host computer system 12 can receive sensor 
dau or a sensor signal via a bus 24 from sensors of interface device 14 and — 
Microprocessor 1 6 can receive data from bus 24 using standard 1/0 electronics provded between 
the microprocessor 16 and the bus 24, and can also use ^ I/O electronics " """^ 
peripheral devices. Host computer system 12 can also output a "force command to tnterface 
device 1 4 via bus 24 to cause force feedback for the interface device. 

Ckx:k 18 is a standard clock crystal or e<,uiva,en, component used by hos, computer 
system 12 to provide timing to electrical signals used by microprocessor 16 and other 

nork lg is accessed by hosi computer system 12 m tne 
components of the computer system. ClocK I5 is acccsbcu vj r 

control process of the present invention, as described subsequently. 
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Display scrcn 20 is coupled .o hos. microprocessor 16 by soluble display drivers and can 
used «, di^..y inures ,en«ared by hos, co™pu,er sys,en, 12 or o|her co-pmer ^s«m. 
KSPU, scrJzO can b. a sundard display screen or CRT, 3-D goggles, o, any o*er vsual 
in Jfie In a described embodin««, display screen 20 displays images of a simulauon or gan« 
^^rJ«. Inod,e,en,bodimen,s.o,her,magescanbedUp..yed. For example. , mages 
robing a pom. of View from a f,rs,-person ^rsf^rive be displayed, as ,n a v,nu.l r^l^- 
Ll«io of game. Or. ,mages describing a Uiird-person P<rspec.ive of 
eu:. can be displayed. A user 22 of d,e hos, computer 12 and m-erface devce 14 can reeve 
visual feedback by viewing display screen 20. 

Herein, computer 12 may be referred as displaying computer -objccu- or ■■=nuues■^ 
•niesecompurerobiecu « no, physical c*jec.. bu. is a logical software unu coUecuons of da. 
and/or p^cedures 0,a. ma, be display^ as images by computer 12 on drsp.ay screen 20. a^^ 
well Jown .oU-ose skilled in *e an. For example, a cursor or a *ird-person of a c. m,gb> 
be considered player-comrolled computer objects that can be moved across the screen. A 
*^^ed. simuLd cckptt of an aircraft might also ^ considered an "objecf. or 0,= simulated 
aircraft can be considered a computer controlled -enuiy". 

Audio output device 21 . such as speakers, is pteferably coupled .0 hos, microprocessor 16 
viaamplifiers. niters, and other circuitry well known toOtose Skilled inU,= an Hos, processor 16 
omputs signals ,o speakers 21 ,o provide sound ouipu, ,o user 22 when an aud,o ven, <k u« 
du,^.g *e implemen«,i.n of *e hos, applica.ion program. 0*er ,ypes of penpherals can ^so be 
coupled ,0 hos, processor 16. such as srorage devices (hard disk drive. CD ROM drive, floppy 
disk drive. e,c.). printers, and odier inpu, and ou,pul devices. 

An imerface device 14 is coupled ,0 hos, computer system 12 by a bl-dlrectional bus 24. 
The bi-directional bus sends signals in eld«r direcUon between hos, compu,er system 12 and the 
interface device. Herein, the tenn "bus" is intended ,0 gerterically refer ,0 an interface such ^ 
bcween hos, compu,er ,7 and microprocessor 26 which typically includes one or mo« 
connecting wires or odier connections and *a. can be implemented in a vaneiy of ways, as 
described below. In the preferred embodiment, bus 24 is a serial interface bus prov,d,ng d^ 
according .o a serial communication pro»col. An interface pori of hos, computer sys.em 12 
, such as an RS232 serial interface pori. connects bus 24 to hos, compu,er sysrem 12. Cher 
sundard serial communic«ion pratocols can also be used in serial in,erface and bus 24 such 
as RS-422. Universal Serial Bus (USB). MIDI, or od,.r protocols well known to those sktlled m 



the art. 
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For example, the USB standard provides a relatively high speed serial interface that can 
provide force feedback signals in the present invention with a high degree of real«m. USB can 
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also source more power to drive peripheral devices. Since each device thai accesses the USB .s 
assigned a unique USB address by the host computer, this allows multiple devices to share the 
same bus. In addition, the USB standard includes timing data that is encoded along w.th 
differendal data. The USB has several useful feamres for the present invention, as descnbed 
throughout this specification. 

An advantage of the present invention is that low-bandwidth serial communication signals 
can be used to interface with interface device 14, dius allowing a standard built-in senal mterface 
of many computers to be used directly. Alternatively, a parallel port of host computer system 2 
can be coupled to a parallel bus 24 and communicate with interface device using a parallel 
protocol such as SCSI or PC Parallel Printer Bus. In a different embodiment, bus 24 can be 
connected directly to a data bus of host computer system 12 using, for example, a plug-.n card 
and slot or other access of computer system 12. For example, on an IBM AT compatible 
computer, the interface card can be implemented as an ISA. EISA. VESA local bus. PCI. or other 
well-known standard interface card which plugs into the motherboard of the computer and 
provides input and output ports connected to the main data bus of the computer. 

In another embodiment, an additional bus 25 can be included to communicate between 
host computer system 12 and interface device 14. Since the speed requirement for 
communication signals is relatively high for outputting force feedback signals, the smgle sena^ 
interface used with bus 24 may not provide signals to and from the interface device at a h.gh 
enough rate to achieve realistic force feedback. In such an embodiment, bus 24 can be coupled to 
the standard serial port of host computer 12. while an additional bus 25 can be coupled to a second 
port of the host computer system. For example, many computer systems include a "game port 
in addition to a serial RS-232 port to connect a joystick or similar game controller to the computer. 
The two buses 24 and 25 can be used simuluneously to provide a increased data bandwidth. For 
example, microprocessor 26 can send sensor signals to host computer 1 2 via a uni-direcuonal bus 
25 and a game port, while host computer 12 can output force feedback signals from a senal port 
to microprocessor 26 via a uni-directional bus 24. Other combinations of data How 
configurations can be implemented in other embodiments. 

interface device 14 includes a local microprocessor 26. sensors 28. actuators 30. a user 
object 34, optional sensor interface 36. an optional actuator interface 38. and other opt.onal mput 
devices 39. Interface device 14 may also include additional electronic components for 
communicatmg via standard protocols on bus 24. In the preferred embodiment, multiple mterface 
devices 14 can be coupled to a single host computer system 12 through bus 24 (or multiple buses 
24) so that multiple users can simultaneously interface with the host application program (m a 
35 multi-player game or simulation, for example). In addition, multiple players can mteracl m the 
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host application program with multiple interface devices 14 using networked host computers 12. 
as is well known to those skilled in the art. 

Local microprocessor 26 is coupled to bus 24 and is preferably included within the 
housing of interface device 14 to allow quick communication with other components of the 

5 interface device. Processor 26 is considered "local" to interface device 14, where "local" herein 
refers to processor 26 being a separate microprocessor from any processors in host computer 
system 12. "Local" also pieferably refers to processor 26 being dedicated to force feedback and 
sensor UO of interface device 14, and being closely coupled to sensors 28 and actuators 30, such 
as within the housing for interface device or in a housing coupled closely to interface device 14. 

10 Microprocessor 26 can be provided with software instnictions to wait for commands or requests 
from computer host 16. decode the command or request, and handle/control input and output 
signals according to the command or request. In addition, processor 26 preferably operates 
independently of host computer 16 by reading sensor signals and calculating appropriate forces 
from those sensor signals, time signals, and a reflex process (also referred to as a "subroutine" or 

15 "force sensation process" herein) selected in accordance with a host command. Suitable 
microprocessors for use as local microprocessor 26 include the MC68HC71 1E9 by Motorola and 
the PIC16C74 by Microchip, for example. Microprocessor 26 can include one microprocessor 
chip, or multiple processors and/or co-processor chips. In other embodiments, microprocessor 
26 can includes a digital signal processor (DSP) chip. Local memory 27. such as RAM and/or 

20 ROM, is preferably coupled to microprocessor 26 in interface device 14 to store instructions for 
microprocessor 26 and store temporary and other data. Microprocessor 26 can receive signals 
from sensors 28 and provide signals to actuators 30 of the interface device 14 in accordance with 
instructions provided by host computer 12 over bus 24. 

In addition, a local clock 29 can be coupled to the microprocessor 26 to provide timing 
25 data, similar to system clock 18 of host computer 12; the timing data might be required, for 
example, to compute forces output by actuators 30 (e.g.. forces dependent on calculated velociues 
or other time dependent factors). In alternate embodiments using the USB coi.imunication 
interface, timing data for microprocessor 26 can be retrieved from USB signal. The USB has a 
clock signal encoded with the data stream which can be used. Alternatively, the Isochronous 
30 (stream) mode of USB can be used to derive timing information from the standard data transfer 
rate. The USB also has a Sample Clock, Bus Clock, and Service Clock that also may be used. 

For example, in one embodiment, host computer 12 can provide low-level force 
commands over bus 24, which microprocessor 26 directly provides to actuators 30. This 
embodiment is described in greater detail with respect to Figure 4. In a different embodiment, 
35 host computer system 12 can provide high level supervisory commands to microprocessor 26 
over bus 24, and microprocessor 26 manages low level force control ("reflex") loops to sensors 
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28 and _ 30 in accordance ^ *e high >cvcl commands. This c«b.di„»n. is dcscnbcd 
in greater detail with respect to Figure 5. 

Microprocssor 26 p«f.rab.y also has acc^s .o an cl«mcally erasable programmable 
ROM (EEPROM) or other memor, storage device 27 for s,ortng calibra^on P™, ^ 

, calibration pa»me«rs can compensa,. io, sligh. manufacnng vanauons .n ''""^^J^Z 
Lenies of a« components ofdifferem ,n.erface de,i«s made from ^ same m^uf^turmg 
Z^such as phyL dimensrons. caiibrauon parameters can be detenntned ^ 
^ manuf Jer befote the tnterface device ,4 is sold, or optionally, the pa«mete. c^ be 
dL^ined by a user of the interface device. The calibration parameurs are used ^ 

, .0 modify the input sensor signals and/or output force values to actuators 30 to p«.v^ 
approximately the same range of forces on object 34 in a large number of '^'-^-' "^2 
devtces ,4. L implementauon of calibration parameters is well-known to those sktlled m the 

art. 

Mictoprocessor 26 can also teceive commands from any other input devices included on 
5 interface apparatus 14 and provides appropriate signals to host computer 12 to tndtcat. that ^ 
inputinfotLation has been received and any infonnation included i";^"P« "^f," 
example, buuons. switches, dials, or other input controls on intef ace dev,« 14 or user object 34 
can provide signals lo microprocessor 26. 

in the prefened embodtmenl. sensors 28. acmators 30. and microprocessor 26. and 
» other related electronic components are included in a housing for interface device 14. to »^.h 
user object 34 is ditectly or indirectly coupled. Alternatively, microprocessor 26 an^or oth 
electronic components of interface device 14 can be provided in a separate h"-"^ /'- " 
object 34. sensors 28. and actuators 30. Also, additional mechanical stmctures may be mclud d ,„ 
interface device 14 toprovide object 34 with desired degrees of freedom. Some embod.mems of 
25 such mechanisms are described with reference to Figures 7-12. 

Sensors 28 sense the position, motion, and/or other characteristics of a us« object 34 of 
the interface device 14 along one or mo« degrees of freedom and provtde stgnals to 
microprocessor 26 including information representative of those characteristics. Examples 
embodiments of user objects ^ movement within provided degrees of fr^dorn are descnW 
30 subsequently with respect to F,gu«s 7 and 8. Typically, a sensor 28 is provtded for each egr« 
of ft^dom along which obj«t 34 can be moved. Alternatively, a single compound sen r c=. be 
used to sense position or movemem in multiple degrees of freedom. An example o, sensor 
suitable for several embodiments described herein are digital optical encoders, whtch sense *e 
change inposition of an objectaboutaroutional axis and provide d.g,^ stgnals ~ "'^^ 
35 change in position. TKe encoder, for example, responds ,o . shaft s r««.on by productng tw. 
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phase-related signals in the rotary degree of freedom. Linear optical encoders similarly sense the 
change in position of object 34 along a linear degree of freedom, and can produces the two phase- 
related signals in response to movement of a linear shaft in the linear degree of freedom. E.ther 
relative or absolute sensors can be used. For example, relative sensors only provide relative angle 
information, and thus usually tequ.re some form of calibration step which provide a reference 
position for the relative angle information. The sensors described herein are primarily relative 
sensors. In consequence, there is an implied calibration step after system power-up wherem a 
sensor's shaft is placed in a known position within interface device and a calibrauon signal .s 
provided to the system to provide the reference position mentioned above. All angles provided by 
the sensors are thereafter relative to that reference position. Alternatively, a known index pulse 
can be provided in the relative sensor which can provide a reference position. Such calibration 
methods are well known to those skilled in the art and. therefore, will not be discussed m any 
great detail herein. A suitable optical encoder is the "Softpof from U.S. Digital of Vancouver. 
Washington. 

i Sensors 28 provide an electrical signal to an optional sensor interface 36. which can be 

used to conven sensor signals to signals that can be interpreted by the microprocessor 26 ard/or 
host computer system 12. For example, sensor interface 36 receives the two phase-related signals 
from a sensor 28 and converts the two signals into another pair of clock signals, which dnve a bi- 
directional binary counter. The output of the binary counter is received by microprocessor 26 as a 

0 binary number representing the angular position of the encoded shaft. Such circuits, or equivalent 
circuits, are well known to those skilled in the art; for example, the Quadrature Chip LS7166 from 
Hewlett Packard. California performs the functions described above. Each sensor 28 can be 
provided with its own sensor interface, or one sensor interface may handle data from multiple 
sensors. For example a sensor interface can include a separate processing chip dedicated to each 

t5 sensor 28 that provides input data. Alternately, microprocessor 26 can perform these interface 
functions without the need for a separate sensor interface 36. T^e position value signals can be 
used by microprocessor 26 and are also sem to host computer system 12 which updates the host 
applicaUon program and sends force control signals as appropriate. For example, if the user 
moves a steering wheel object 34. the computer system 12 receives position and/or other signals 

30 indicating this movement and can move a displayed point of view of the user as ,f looking out a 
vehicle and turning the vehicle. Other interface mechanisms can also be used to provide an 
appropriate signal to host computer system 12. In alternate embodiments, sensor signals from 
sensors 28 can be provided directly to host computer system 12, bypassing microprocessor 26. 
Also, sensor interface 36 can be included within host computer system 12. such as on an interface 

35 board or card. 
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Alternatively, an analog sensor can be used instead of digital sensor for all or some of the 
sensors 28. For example, a strain gauge can be connected to measure forces on object 34 rather 
than positions of the object. Also, velocity sensors and/or accelerometers can be used to directly 
measure velocities and accelerations on object 34. Analog sensors can provide an analog signal 
representative of the position/velocity/acceleration of the user object in a panicular degree of 
freedom. An analog to digital converter (ADC) can convert the analog signal to a digital signal 
that is received and interpreted by microprocessor 26 and/or host computer system 12, as is well 
known to those skilled in the art. The resolution of the detected motion of object 34 would be 
limited by the resolution of the ADC. However, noise can sometimes mask small movements of 
object 34 from an analog sensor, which can potentially mask the play that is important to some 
embodiments of the present invention (described subsequently). 

Other types of interface circuitry 36 can also be used. For example, an electronic interface 
with a separate processing chip for each sensor can be used. The interface allows the position of 
the mouse or stylus to be tracked and provides force feedback to the stylus using sensors and 
actuators. Sensor interface 36 can include angle determining chips to pre-process angle signals 
reads from sensors 28 before sending them to the microprocessor 26. For example, a data bus 
plus chip-enable lines allow any of the angle determining chips to communicate with the 
microprocessor. A configuration without angle-determining chips is most applicable in an 
embodiment having absolute sensors, which have output signals directly indicating the angles 
without any further processing, thereby requiring less computation for the microprocessor 26 and 
thus little if any pre-processing. If the sensors 28 are relative sensors, which indicate only the 
change in an angle and which require further processing for complete determination of the angle, 
then angle-determining chips are more appropriate. 

Actuators 30 transmit forces to user object 34 of the interface device 14 in one or more 
directions along one or more degrees of freedom in response to signals received from 
microprocessor 26. Typically, an actuator 30 is provided for each degree of freedom along which 
forces are desired to be transmitted. Actuators 30 can include two types: active actuators and 
passive actuators. 

Active acniators include linear current control motors, stepper motors, 
pneumatic/hydraulic active actuators, and other types of acniators that transmit a force to move an 
object. For example, active actuators can drive a rotational shaft about an axis in a rotary degree of 
freedom, or drive a linear shaft along a linear degree of freedom. Active transducers of the 
present invention arc preferably bi-directional, meaning they can selectively transmit force along 
either direction of a degree of freedom. For example. DC servo motors can receive force control 
signals to control the direcUon and torque (force output) thai is produced on a shaft. Tlie motors 
may also include brakes which allow the rotation of the shaft to be halted in a shon span of time. 
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0U« ,yp« of «uv. mo,o. c» ^so be used, such as a s.epp« ™o», co„™. .d w„h puis 
»,p.l.r range), o, a voice coil a=a.a.o,. ««Hch are well know, .o .hose skUled ,n U« an. 

Passive aerators can also be used for .cma,ors 30. Magnetic panicle bakes fricnon 
brakes or pneumatic/hydraulic passive acmaiors can be used in »WiU«n .0 or ,ns,e«l of a motor 
o Tnera, a dantping resistance or fHaion in a degree of tnoUon. An altera, prefer. 
1 odimen, only ilduding passive actuators nta, no. be as realisUc as -^ -^'^'^"^^^ 
motors- however the passive actuators are typically safer for a user stnce the user does no. have to 
^ ; eld f J Passive actuators typically can only provide bi-directional resist™ 
degree of motion. A suitable magneuc p^ide brake for interface devi. ,4 .s avatiable from 
Force Limited, Inc. of Santa Monica. California. 

,„ alternate embodiments. ^1 or some of sensors 28 and actuators 30 can be includ^ 
together as a sensor/actuator patr transducer. A suitable transducer for t^ present tnvenu^ 
,„Ld,ng bo.h an opttc. encoder and cunen, controlled m„»r is a 20 W basket wound servo 
motor manufactured by Maxon. 

Actuator interface 38 can be opuonally co„.«c.ed hetw«n actuatot. 30 »d 
microprocessor 26. Interface 38 convens signals from microprocessor 26 tn.o stgnals approprtale 
:d~a,ors 30. Interface 38 can include power amplifiers, swiuhes. digiul .o 
controllers ,DACs,, and other components. An e.amp.e of an ;« 
actuators is described with refe^uce to Bgure 2. An example of an acntator tnterface or p^s vc 
actuators ,s descdbed w,th tefe^nce to F.gore 3. In altem« embodtments. mterface 38 cfcutto 
can be provided within microproces.ior 26 or in actuators 30. 

Other input devices 39 can optionally be included in intetface devtcc 14 and send ittpu. 
signals to microprocessor 26. Such input devices can include buttons, dials, swttches, or othe 

rchanisms. For example, in etnbodiments where user ob.c. 34 ts ' >^^^^;J^ 
devieeseanincludeoncor more bu«onsprov,ded,for example, on thepysttckhandleo,^^^^^^^ 

used to supplement the input from the user to a game or stmulation. The operauon of such tnput 
devices is well known to those skilled in the art. 

Power supply 40 can optionally be coupled .0 acn.a.or interface 38 and/or acnta^rs 30 to 
, provide eleemcal power. Active acmators typi^lly require a separ«e power source to be t^ve. 
Power supply 40 can be included within the housing of intetface device 14. or can be provtded as 
a separate component, for example, connected by an electrical power cord. 

Altentadvely. if the USB or a similar communication protocol is '^''■j^'"/''^* 
can draw power frotn the USB and thus have no need for power supply 40, Thts «nbod,m.m ts 
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most applicable to a device 14 having passive actuators 30. since passive actuaton require httle 
power to operate. Active actuators tend to require more power than can be drawn from USB, but 
this restriction can be overcome in a number of ways. One way is to configure interface 14 to 
appear as more than one peripheral to host computer 12; for example, each provided degree of 
freedom of user object 34 can be configured as a different peripheral and receive its own allocation 
of power This would allow host 12 to allocate more power to interface device 14. Alternatively, 
power from the USB can be stored and regulated by interface device 14 and thus used when 
needed to drive actuators 30. For example, power can be stored over time and then immediately 
dissipated to provide a jolt force to the user object 34. A capacitor circuit, for example, can store 
the energy and dissipate the energy when enough power has been stored. Microprocessor may 
have to regulate the output of forces to assure that time is allowed for power to be stored. This 
power storage embodiment can also be used in non-USB embodiments of interface device 14 to 
allow a smaller power supply 40 to be used. 

Safety switch 41 is preferably included in interface device to provide a mechanism to 
allow a user to override and deactivate actuators 30. or require a user to activate actuators 30. for 
safety reasons. Certain types of actuators, especially active actuators such as motors, can pose a 
safety issue for the user if the acmators unexpectedly move user object 34 against the user with a 
strong force. In addition, if a failure in the control system 10 occurs, the user may desire to 
quickly deactivate the actuators to avoid any injury. To provide this option, safety switch 41 is 
20 coupled to actuators 30. In the preferred embodiment, the user must continually activate or close 
safety switch 41 during operation of interface device 14 to activate the actuators 30. If, at any 
time, the safety switch is deactivated (opened), power from power supply 40 is cut to actuators 30 
(or the actuators are otherwise deacnvated) as long as the safety switch is deactivated. For 
example, a preferred embodiment of safety switch is an optical switch located on user object 34 
25 (such as a joystick) or on a convenient surface of a housing enclosing interface device 14. When 
the user covers the optical switch with a hand or finger, the sensor of the switch is blocked from 
sensing ambient light, and the switch is closed. The actuators 30 thus will function as long as the 
user covers the switch. Other types of safety switches 4 1 can be provided in other embodiments. 
For example, an electrostatic contact switch can be used to sense contact, a button or trigger can be 
30 pressed, or a different type of sensor switch can be used. 

User object 34 is preferably a device or article that may be grasped or otherwise contacted 
or controlled by a user and which is coupled to interface device 14. By "grasp", it is meam that 
users may releasably engage a grip portion of the object in some fashion, such as by hand, with 
their fingertips, or even orally in the case of handicapped persons. The user 22 can manipulate 
35 and move the object along provided degrees of freedom to interface with the host application 
program the user is viewing on display screen 20. Object 34 can be a joystick, mouse, trackball, 
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Stylus, steering wheel, medical instniment (laparoscope, catheter, etc.). pool cue. hand grip, knob, 
button, or other article. 

Figure 2 is a schematic diagram illustrating an example of an actuator interface 38 for an 
active acmator 30 of interface device 14. In this example, actuator 30 is a linear current controlled 
servo motor. Actuator interface 38 includes a DAC circuit 44 and a power amplifier circu.t 46. 

DAC circuit 44 is coupled to microprocessor 26 and preferably receives a digital signal 
representing a force value from the microprocessor 26. DAC 48 is suitable for converting an 
input digital signal to an analog voltage thai is output to power amplifier circuit 46. A suitable 
DAC 48 is a parallel DAC. such as the DAC 1220 manufactured by National Semiconductor, 
which is designed to operate with external generic op amp 50. Op amp 50, for example, outputs a 
signal from zero to -5 volts proportional to the binary number at its input. Op amp 52 is an 
invcrtmg summing amplifier that converts the output voltage to a symmetrical bipolar range. Op 
amp 52 produces an output signal between -2.5 V and +2.5 V by inverting the output of op amp 
50 and subtracting 2.5 volts from that output; this output signal is suitable for power ampl.f.caiion 
in amplification circuit 46. As an example. Rl = 200 kW and R2 = 400 kW. Of course, DAC 
circuit 44 is intended as one example of many possible circuits that can be used to convert a digital 
signal to a desired analog signal. 

Power amplifier circuit 46 receives an analog low-power control voltage from DAC circuit 
44 and amplifies the voltage to control acmaiors 30. Actuator 30 can be a high-power, currcm- 
controllcd servo motor 30. The input voltage controls a transconductance stage composed of 
amplifier 54 and several resistors. The transconductance stage produces an output currem 
proponional to the input voltage to dnve motor 30 while drawing very little current from the input 
voltage source. The second amplifier stage, including amplifier 56. resistors, and a capacitor C. 
provides additional currem capacity by enhancing the voltage swing of the second terminal 57 o^f 
25 motor 30. As example values for power amplifier circuit 46. R = 10 kW . R2 = 500 W. R3 - 
9.75 kW and R4 = 1 W. Of course, circuit 46 is intended as one example of many possible 
circuits that can be used to amplify voltages to drive active actuators 30. 

Figure 3 is a schematic diagram illustrating an example of an actuator interface 38' that can 
be used in conjunction with passive actuators. Interface 38' is suitable for use with passive 

30 actuators (dampers) that are controlled with an analog voltage, such as magnetic particle brakes or 
a variable solenoid that can be used with fiuid controlled passive dampers, for example. Interface 
38' includes a DAC circuit 44. amplifier 60, transistor 62, and voltage protector 64. DAC circuit 
44 is coupled to microprocessor 26 and receives a digital signal from the computer system 
representing a resistive force value to be applied to user object 34. DAC circuit 44 converts the 

35 digital signal voltages to analog voltages which are then output to amplifier 60. A suitable DAC is 
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the MAX530ACNG manufactured by Maxim, or DAC circuit 44 as described above wth 
reference to Figure 2. Amplifier 60 receives the analog voltage from DAC 44 on a posiuve 
teiminaJ and scales the voltage signal to a range usable by actuator 30. Amplifier 60 can be 
implemented as an operational amplifier or the like. Transistor 62 is coupled to the output of 
amplifier 60 and preferably operates as an amplifier to provide increased output current to actuator 
30. Resistor Rl is coupled betvi^een amplifier 60 and the emitter of transistor 62. and resistor R2 
is coupled between amplifier 60 and ground. For example, resistors Rl and R2 can have values 
of 180 kfl and 120 kD. respectively, and provide the proper biasing in the circuit. Voltage 
protector 64 is coupled to the emitter of transistor 62 and provides protection from voltage spikes 
when using inductive loads. Suitable passive actuators 30 for use with this circuitry includes 
variable solenoids or magnetic particle brakes. A separate DAC and amplifier can be used for 
each actuator 30 implemented in the interface apparatus so the microprocessor 26 and/or host 
computer system 12 can control each acniator separately for each provided degree of freedom. 
Interface 38' is intended as one example of many possible circuits that can be used to interface a 
computer system to actuators. 

In an alternate embodiment, an on/off signal might only be needed, for example, for a 
solenoid driving an on/off valve of a fluid-controlled actuator. In such an embodiment, for 
example, a transistor can be electrically coupled to microprocessor 26 at its base terminal to 
operate as an electrical switch for controlling the activation of a solenoid in the on/off actuator 30. 
A force signal such as a TTL logic signal can be sent to control the transistor to either allow 
current to fiow through the solenoid to activate it and allow free movement of object 43, or to 
allow no current to flow to deactivate the solenoid and provide resistance to movement. 

Figure 4 is a flow diagram illustrating a first embodiment of a method 70 for controlling a 
force feedback interface device of the present invention. Method 70 is directed to a • host- 
controlled" embodiment, in which host computer system 12 provides direct, low-lcvcl force 
commands to microprocessor 26. and the microprocessor directly provides these force 
commands to actuators 30 to control forces output by the actuators. 

For example, the host controlled mode is suitable for embodiments using a USB 
communication interface. Data rates are sufficiently high to allow the host to communicate at 500 
Hz or greater and provide realistic force feedback to the user object 34. The USB Isochronous 
Data Transfer mode of USB is suitable to provide the necessary high data rate. 

The process begins at 72. In step 74, host computer system 12 and interface device 14 are 
powered up. for example, by a user activating power switches. After step 74, the process 70 
branches into two parallel (simultaneous) processes. One process is implemented on host 
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computer system 12. and the other process is implemerted on local microprocessor 26. These 
two processes branch out of step 74 in different directions to indicate this s.multane.ty . 

In the host computer system process, step 76 is ftrst implemented, in which an application 
program is processed or updated. This application can be a simulation, video game, sc.ent.fic 
5 program, or other program. Images can be displayed for a user on output display screen 20 and 
other feedback can be presented, such as audio feedback. 

Two branches exit step 76 to indicate that there are two processes running simultaneously 
(multitasking) on host computer system 12. In one process, step 78 is implemented^ where 
sensor data is received by the host computer from local microprocessor 26. As detailed below .n 
,0 the microprocessor process, the local processor 26 continually receives signals rom sensors 28 
processes the raw data, and sends processed sensor data to host computer 12. Altemat.ve^^ 

processor 26 sends raw data directly to host computer system 12. "Sensor data - referred t° 
herein, can include position values, velocity values, and/or acceleration values denved from the 
sensors 28 which detect motion of object 34 in one or more degrees of freedom. In add.uon. any 
15 other data received from other input devices 39 can also be received by host computer system 12 
as sensor data in step 78. such as signals indicating a button on interface dev.ce 14 has been 
activated by the user. Fmally, the tem. "sensor data" also can include a history of values, such as 
position values recorded previously and stored in order to calculate a velocity. 

After sensor data is read m step 78. the process returns to step 76. where the host 
20 computer system 12 can update the applicat.on program .n response to the users manipulations of 
object 34 and any other user input received ,n step 78 as well as detemiine if forces need to be 
applied to object 34 ,n the parallel process. Step 78 ts implemented in a continual loop of readmg 
data from local processor 26. 

The second branch from step 76 is concerned with the process of the host computer 
25 determining force commands to provide force feedback to the user manipulating object 34. mse 
commands are described herein as "low-level" force commands, as distinguished from the high- 
level" or supervisory force commands described in the embodiment of Figure 5. A low level 
force command instructs an actuator to output a force of a particular magnitude. For example the 
low level command typically includes a magnitude force value, e.g.. equivalent signaKs) to 
30 instruct the actuator to apply a force of a desired magninide value. Low level force commands 
may also designate a direction of force if an actuator can apply force in a selected direction, and/or 
other low-level information as required by an actuator. 

The second branch starts with step 80. in which the host computer system checks if a 
change in the force applied to user object 34 is required. Hiis can be detemuned by several types 
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Of criteria, the most important of which are the sensor data read by the host coniputer in step 78. 
uming daia. and the implementation or "events" of the application program updated in step 76. 
The sensor data read in step 78 informs the host computer 12 how the user is interacting with the 
application program. From the position of object 34 sensed over time, the host computer system 
12 can determine when forces should be applied to the object. For example, if the host computer 
is implementing a video game application, the position of a computer generated object within the 
game may determine if a change in force feedback is called for. If the user is controlling a 
simulated race car. the position of the user object joystick determines if the race car is moving into 
a wall and thus if a collision force should be generated on the joystick. In addition, the velocity 
and/or acceleration of the user object can influence whether a change in force on the object is 
required. If the user is controlling a tennis racket in a game, the velocity of a user object joystick 
in a particular degree of freedom may determine if a tennis ball is hit and this if an appropriate 
force should be applied to the joystick. Also, other input, such as a user activating buttons or 
other controls on interface device 14. can change the forces required on object 34 depending on 
how those controls have been programmed to affect the application program. 

Other criteria for detennining if a change in force is required includes events in the 
application program. For example, a game application program may (perhaps randomly) 
detennine that another object in the game is going to collide with an object controlled by the user, 
regardless of the position data of the user object 34. Forces should thus be applied to the user 
object dependent on this collision event to simulate an impact. Forces can be required on the user 
object depending on a combination of such an event and the sensor data read in step 78. Other 
parameters in the application program can determine if a change in force to the user object is 
necessary, such as other input devices or user interface devices connected to host computer 
system 12 and inputting data to the application program (other interface devices can be directly 
connected, connected remotely through a network, etc.). 

If no change in force is currently required in step 80. then the process returns to step 76 to 
update the host application and return to step 80 to again check until such a change in force is 
required. When such a change is required, step 82 is implememed, in which host computer 12 
detennines appropriate low-level force commands to be sent to the actuators 30 of interface device 
14, these force commands being dependent on a selected force sensation process, sensor data, the 
host application, and the clock 1 8. 

The low-level force commands can be determined, in part, from a selected force sensation 
process. A "reflex process" or "force sensation process" (also called a "subroutine"), as referred 
to herein, is a set of instnictions for providing force commands dependem on other parameters, 
such as sensor data read in step 78 and timing data from clock 1 8. In the described embodiment, 
force sensation processes can include several different types of steps and/or instnictions. One 
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type of insimciion is a force algorithm, which includes an equation that host computer 1 2 can use 
to Calculate or model a force value based on sensor and t.m.ng data. Several types of algorUhtns 
can be used. For example, algorithms in which force varies linearly (or nonlinearly) wtth the 
position of object 34 can be used to provide a simulated force like a spring. Algorithms .n which 
Le varies linearly (or nonlinearly) w.th the velocity of object 34 can be also used to prov.dc a 
simulated damping fon:e or other forces. Algorithms in which force varies hnearly (or 
nonlinearly) with the accelerauon of object 34 can also be used to provide, for example a 
simulated inertia! force on a mass (for linear variation) or a simulated graviuttonal pull (for 
nonlmear variation). Several types of simulated forces and the algorithms used to calculate such 
forces are described in "Perceptual Design of a Virtual Rigid Surface Contac. by Lou.s B. 
Rosenberg. Center for Design Research. Stanford University. Report number AUCF-TR-1995- 
0029, April 1993. which is incorporated by reference herein. 

For force values depending on the velocity and acceleration of user object 34. the velocity 
and acceleration can be provided in a number of different ways. The sensor data read by host 
computer 12 in step 78 can include position data, velocity data, and acceleration data. In a 
preferred embod.ment. the velocity and acceleration data was calculated previously by 
microprocessor 26 and then provided to the host computer 12. The host computer can thus use 
the velocity and acceleration data directly in an algonthm to calculate a force value. In an alternate 
embodiment, the sensor data read m step 78 includes position data and no velocity or acceleration 
data so that host computer 12 is required to calculate the velocity and acceleration from the 
position data. "Hiis can be accomplished by recording a number of past position values, recording 
the time when each such position value was received using the system clock 18. and calculating a 
velocity and/or acceleration from such data. 

For example, a kinematic equation which calculates a force based on the velocity of the 
user object multiplied by a damping constant can be used to determine a damping force on the 
user object. This type of equation can simulate motion of object 34 along one degree of freedorn 
uirough a fluid or similar material. For example, a damping constant can first be selected which 
indicates the degree of resistance that object 34 experiences when moving through a simulated 
material, such as a liquid, where a greater number indicates greater resistance. For example, water 
would have a lower damping constant than oil or syrup. The host computer recalls the previous 
position of user object 34 (along a particular degree of freedom), examine the current position of 
the user object, and calculate the difference in position. From the sign (negative or positive) of the 
difference, the direction of the movement of object 34 can also be determined. THe force is then 
set equal to the damping constant multiplied by the change in position. Commands that controlled 
an actuator based on this algorithm would produce a force proportional to the user object s motion 
to simulate movement through a fluid. Movement in other mediums, such as on a bumpy 
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surface, on an inclined plane, etc.. can be simulated in a similar fashion using different methods of 
calculating the force. 

The detennination of force commands is preferably influenced by timing data accessed 
from system clock 1 8. For example, in the damping force example described above, the velocity 

5 of the user object 34 is determined by calculating the different of positions of the user object and 
multiplying by the damping constant. This calculation assumes a f.xed time interval between data 
points, i.e.. it is assumed that the posiuon data of the object 34 is received by host computer 12 m 
regular, predetermined time intervals. However, this may not actually occur due to different 
processing speeds of different computer platforms or due to processing variations on a single host 

,0 microprocessor 16, such as due to multitasking. Therefore, in the present invention, the host 
computer preferably accesses clock 12 to determine how much time has actually elapsed since the 
last position data was received. In the damping force example, the host computer could take the 
difference in position and divide it by a time measure to account for differences in liming. "Hie 
host computer can thus use the clock's timing data in the modulation of forces and force 

15 sensations to the user. Timing data can be used in other algorithms and force sensation processes 
of the present invention to provide repcatable and consistent force feedback regardless of type of 
platform or available processing lime on host computer 12. 

Other instructions can also be included in a force sensation process. For example, 
conditions can be included to provide forces only in desired directions or under other particular 

20 circumstances. For example, to simulate a vimial obstmction such as a wall, forces should be 
applied in only one direction (uni-direciional). For many passive actuators, only bi-directional 
resistance forces can be applied. To simulate uni-dircction resistance, conditions can be included 
in the virtual obstruction force sensation process. An example of such conditions in a virtual 
obstruction force sensation process is described with respect to Figure 12. Also, a "null" reflex 

25 process can be available that instructs host computer 12 {or microprocessor 26 in the embodiment 
of Figure 5) to issue a low level command or force values to provide zero forces (i.e. remove all 
forces) on user object 34. 

Another type of force sensation process does not use algorithms to model a force, but 
instead uses force values that have been previously calculated or sampled and stored as a digitized 

30 "force profile" in memory or other storage device. These force values may have been previously 
generated using an equation or algorithm as described above, or provided by sampling and 
digitizing forces. For example, to provide a particular force sensation to the user, host computer 
12 can be instructed by a force sensation process to retrieve successive force values from a certain 
storage device, such as RAM. ROM, hard disk. etc. These force values can be sent directly to an 

35 actuator in a low-level command to provide particular forces without requiring host computer 12 
to calculate the force values. In addition, previously-stored force values can be output with respect 
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to other parameters to provide different types of forces and force sensations from one set of stored 
force values. For example, using system clock 18, the stored force values can be output m 
sequence according to a particular time interval that can vary depending on the desired force. Or, 
different retrieved force values can be output depending on the current position of user object 34. 

Host computer 12 can determine a force command in step 82 according to a newly- 
selected reflex process, or to a previously selected reflex process. For example, if this is a second 
or later iteration of step 82, the same reflex process as in the previous iteration can be again 
implemented if parameters (such as the position of object 34) allow it, as determined by the host 
application program. 

The force command determined in step 82 can also depend on instructions thai check for 
other parameters, "n^ese instructions can be included within or external to the above-descnbed 
reflex processes. One such parameter a« values provided by tfie implemented host appl.cat.on 
program (if any). The application program may determine that a particular force command 
should be output or reflex process implemented based on events occurring within the appl.cat.on 
5 program or other instructions. Force commands or values can be provided by the host appl.cauon 
program independently of sensor data. Also, the host application program can prov.de .ts own 
particular position, velocity, and/or acceleration data to a selected reflex process to calculate or 
provide a force that is not based on the manipulation of user object 34. but is provided to s.mulate 
an evem in the application program. Such events may include collision events, such as occur 
0 when a user^ontrollcd computer image impacts a vimial surface or structure. Also, other tnpu. 
devices connected to host computer 12 can influence events and, therefore, the forces appi.ed to 
user object 34. For example, the sensor data from multiple interface devices 14 connected to a 
single host computer can influence the forces felt on other connected interface devices by 
influencing events and computer-controlled images/objects of the host application program. 

25 Also the force commands detcmtined in step 82 can be based on other inputs to host 

computer 12, such as activations of buttons or other inn-it devices in (or external to) interface 
device 14. For example, a particular application program might require that a force be appi.ed to a 
joystick whenever a user presses a fire button on the joystick. 

The above-described reflex processes and other parameters can be used to provide a 
30 variety of haptic sensations to the user through the user object 34 to simulate many different types 
of tactile events. For example, typical haptic sensations may include a virtual damping (descnbed 
above), a virtual obstn:ction. and a virtual texmre. Virtual obstructions an^ provided to s.mulate 
walls, obstnictions. and other uni-directional forces in a simulation, game. etc. When a user 
moves a computer image into a virtual obstruction with a joystick, the user then feels a physical 
35 resistance as he or she continues to move the joystick in that direction. If the user moves the 
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Object away from the obstruction, the uni-directional force is removed. Thus the user is given a 
convincing sensation that the virtual obstruction displayed on the screen has physical properties. 
Similarly, virtual textures can be used to simulate a surface condition or similar texmre. For 
example, as the user moves a joystick or other user object along an axis, the host computer sends 
a rapid sequence of commands to lepeutivcly 1) apply resistance along that axis, and 2) to then 
immediately apply no resistance along that axis, as according to a reOex process. This frequency 
is based upon the travel of the joystick handle and is thus ccirclated with spatial position. Thus, 
the user feels a physical sensation of texnare. which can be described as the feeling of dragging a 
stick over a grating. 

In next step 84, a low-level force command determined in step 82 is output to 
micK)processor 26 over bus 24. This force command typically includes a force value that was 
determined in accordance with the parameters described above. The force command can be 
output as an actual force signal that is merely relayed to an actuator 30 by microprocessor 26; or. 
the force command can be converted to an appropriate fonn by microprocessor 26 before being 
sent to acmator 30. In addition, the low-lcvel force command preferably includes information 
indicating to microprocessor 26 which aauaiors are to receive this force value (if multiple 
actuators are included on interface device 14). The process then returns to step 76 to 
process/update the host application program. The process continues to step 80. where the host 
computer checks if a different force command should be output as determined by the parameters 
described above. If so. a new force command is determined and output in step 84. If no change 
of force is required, host computer 12 does not issue another command, since microprocessor 26 
can continues to output the previous force command to actuators 30 (alternatively, host computer 
12 can continue to output commands, even if no change of force is required). Subsequent force 
commands output in step 84 can be determined in accordance with the same reflex process, or a 
different reflex process, depending on the parameters of step 82. 

In addition, the host computer 12 preferably synchronizes any appropriate visual feedback, 
auditory feedback, or other feedback related to the host application with tht application of forces 
on user object 34. For example, in a video game application, the onset or start of visual events, 
such as an object colliding with the user on display screen 20, should be synchronized with the 
onset or start of forces felt by the user which correspond to or complement those visual events. 
The onsets visual events and force events are preferably occur within about 30 milliseconds (ms) 
of each other. This span of time is tht topical limit of human perceptual ability to perceive the 
events as simultaneous. If the visual and force events occur outside tiiis range, then a time lag 
between ti>c events can usually be perceived. Similarly, the output of auditory signals, 
corresponding to the onset of auditory events in the host application, are preferably output 
synchronized with tije onset of output forces that cortcspond to/complcnKnt those auditory 
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events. Again, the onsets of these events occur preferably within about 30 ms of each other. For 
example, host computer system 12 can output sounds of an explosion from speakers 21 as close 
in time as possible to the forces felt by the user from that explosion in a simulation. Preferably, 
the magnitude of the sound is in direct (as opposed to inverse) proportion to the magnitude of the 
forces applied to user object 34. For example, during a simulation, a low sound of an explosion 
in the far (virtual) distance can cause a small force on user object 34. while a large, "nearby- 
explosion might cause a loud sound to be output by the speakers and a correspondmgly large 
force to be output on object 34. 

The local microprocessor 26 implements the process branching from step 74 and starting 
with step 86 in parallel with the host computer process described above. In step 86. the interface 
device 14 is activated. For example, signals can be sem between host computer 12 and mterface 
device 14 to acknowledge that the interface device is now active. From step 86. two processes 
branch to indicate that there arc two processes running simultaneously (multi-iaskmg) on local 
processor 26. In one process, step 88 is implemented, in which the processor 26 reads raw data 
(sensor readings) from sensors 28. Such raw data preferably includes position values descnbing 
the position of the user object along provided degrees of freedom. In the preferred embodimem. 
sensors 28 are relative sensors that provide position values describing the change in position since 
the last position read. Processor 26 can detemiine the absolute position by measuring the relative 
position from a designated reference position. In alternate embodiments, sensors 28 can include 
velocity sensors and accelerometers for providing raw velocity and acceleration values of object 
34. The raw data read in step 88 can also include other input, such as from an activated button or 
other control 39 of interface device 14. 

In next step 90. processor 26 processes the received raw dau into sensor data, if 
applicable. In the preferred embodiment, this processing includes two steps, computing velocity 
and/or acceleration values from raw position data (if velocity and/or acceleration are needed to 
compute forces), and filtering the computed velocity and acceleration data. Hie velocity and 
acceleration values are computed from raw position data received in step 88 and stored position 
and time values. Preferably, processor 26 stores a number of posiuon values and time values 
corresponding to when the position values were received. Processor 26 can use its own or a local 
system clock (not shown in Fig. 1) to detemiine the timing data. The velocity and acceleration can 
be computed using the stored position data and timing data, as is well known to those skilled m 
the art. Hie calculated velocity and/or acceleration values can then be filtered to remove noise 
from the data, such as large spikes that may result in velocity calculations from quick changes in 
position of object 34. Thus, the sensor data in the described embodiment includes pos.uon. 
velocity, acceleration, and other input data. In an alternate embodiment, circuitry that is electncally 
coupled to but separate from processor 26 can receive the raw dau and determine velocity and 

26 



wo 97/12357 



PCT/US96/15373 



accelemion. For example, an application-speciHc integrated circuit (ASIC) or discrete logic 
circuitry can use counters or the like to determine velocity and acceleration to save processing t,me 
on microprocessor 26. 

Alternatively, step 90 can be omined. and the processor 26 can provide raw position data 
5 to host computer 12 (and other input data from other input devices 39). This would require host 
computer 12 to filter and compute velocity and acceleration from the position data. Thus, it is 
preferred that processor 26 do this processing to reduce the amount of processing performed on 
host computer 12. In other embodiments, the filtering can be performed on host computer 12 
while the velocity and acceleration calculation can be perfonned on the processor 26. Also, m 
,0 embodiments where velocity and/or acceleration sensors aie used to provide raw velocity and 
acceleration data, the calculation of velocity and/or acceleration can be omitted. After step 90. step 
91 is implemented, in which the processor 26 sends the processed sensor dau to the host 
computer 12 via bus 24. The process then returns to step 88 to read raw data. Steps 88. 90 and 
91 are thus continuously implemented to provide current sensor data to host computer system 12. 

,5 The second branch from step 86 is concerned with processor 26 controlling the actuators 

30 to provide forces calculated by host computer 12 to object 34. The second branch starts with 
step 92 in which processor 26 checks if a low-level force command has been received from host 
computer 12 over bus 24. If not. the process continually checks for such a force command. 
When a force command has been received, step 94 is implemented, in which processor 26 

20 outputs a low-level processor force command to the designated actuators to set the output force to 
the desued magnitude, direction, etc. This force command may be equivalent to the received low- 
level command from the host computer, or. the processor 26 can optionally conven the force 
command to an appropriate form usable by actuator 30 (or actuator interface 38 can perform such 
conversion). The process then returns to step 92 to check for another force command from the 

25 host computer 12. 

Figure 5 is a flow diagram illustrating a second embodiment of a meihod 100 for 
controlling force feedback interface device 14 of the present invention. Method 100 is directed to 
a "reflex" embodiment, in which host computer system 12 provides only high-level supervisory 
force commands ("host commands") to microprocessor 26. while the microprocessor 
30 independently determines and provides low-level force commands (force values) to actuators 30 
as an independent "reflex" to control forces output by the actuators. 

The process of Figure 5 is suiuble for low speed communication interfaces, such as a 
standard RS-232 serial interface. However, the embodiment of Figure 5 is also suitable for high 
speed communication interfaces such as USB. since the local microprocessor relieves 
35 computational burden from host processor 16. In addition, this embodiment can provide a 
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Straightforward command protocol, an example of which is described with respect to Figures 9 
and 14, and which allow software developers to easily provide force feedback in a host 
application. In this embodiment, for example, the slower "intemipt data transfers" mode of USB 
can be used. 

The process begins at 102. In step 104, host computer system 12 and interface device 14 
are powered up. for example, by a user activating power switches. After step 104. the process 
100 branches into two parallel processes. One process is implemented on host computer system 
12, and the other process is implemented on local microprocessor 26. 

In the host computer system process, step 106 is first implemented, in which an 
application program is processed. This application can be a simulation, video game, scientific 
program, or other program. Images can be displayed for a user on output display screen 20 and 
other feedback can be presented, such as audio feedback. 

Two branches exit step 106 to indicate that there are two processes running simultaneously 
(multi-tasking, etc.) on host computer system 12. In one of the processes, step 108 is 
implemented, where sensor data from the user object is received by ihc host computer from local 
microprocessor 26. Similarly to step 78 of the process of Figure 4. host computer system 12 
receives either raw data (e.g.. position data and no velocity or acceleration data) or processed 
sensor data (position, velocity and/or acceleration data) from microprocessor 26. In addition, any 
other data received from other input devices 39 can also be received by host computer system 12 
from microprocessor 26 in step 108. such as signals indicating a button on interface device 14 has 
been pressed by the user. 

Unlike the previous embodiment of Figure 4. the host computer does not calculate force 
values from the received sensor data in step 108. Rather, host computer 12 monitors the sensor 
data to determine when a change in the type of force is required. This is described in greater detail 
below. Of course, host computer 12 also uses the sensor data as input for the host application to 
update the host application accordingly. 

After sensor data is received in step 108, the process returns to step 106, where the host 
computer system 12 can update the application program in response to the user's manipulations of 
object 34 and any other user input received in step 108. Step 108 is then implemented again in a 
continual loop of receiving sets of sensor dau from local processor 26. Since the host computer 
does not need to directly control actuators based on sensor data, the sensor data can be provided at 
a much lower speed. For example, since the host computer updates the host application and 
images on display screen 20 in response to sensor data, the sensor data heed only be read at 60-70 
Hz (the refresh cycle of a typical display screen) compared to the much higher rate of about 500- 
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1000 Hz (or greater) needed to realistically provide low-level force feedback signals from sensor 
signals. Host computer 12 also preferably synchronizes visual, audio, and force events similarly 
as described above with reference to Figure 4. 

The second branch from step 106 is concerned with the process of the host computer 

5 determining high-level force commands ("host commands") to provide force feedback to the user 
manipulating object 34. The second branch starts with step 110. in which the host computer 
system checks if a change in the type of force applied to user object 34 is required. The "type" of 
force is a force sensation or profile produced by a particular reflex process or force value which 
the local microprocessor 26 can implement independently of the host computer. The host 

10 computer 1 2 determines whether a change in the type of force is required depending on the sensor 
data read by the host computer in step 108 and depending on the events of the application program 
updated in step 106. As explained with reference to Figure 4, the sensor data informs the host 
computer when forces should be applied to the object based on the object's current position, 
velocity, and/or accelerauon. The user's manipulations of object 34 may have caused a new type 

15 of force to required. For example, if the user is moving a virtual race car within a virtual pool of 
mud in a video game, a damping type of force should be applied to the object 34 as long as the 
race car moves within the mud. Thus, damping forces need to be continually applied to the object, 
but no change in the type of force is required. When the race car moves out of the pool of mud, a 
new type of force (i.e. a removal of damping force in this case) is required. The events of the 

20 application program may also require a change in the type of force applied. For example, if the 
user's car is traveling through mud and another car collides into the user's car, then a new type of 
force (collision force) should be applied to the user object. Forces may be required on the user 
object depending on a combination of an application event and the sensor data read in step 108. 
Also, other input, such as a user activating buttons or other input devices 39 on interface device 

25 14. can change the type of forces required on object 34. 

If no change in the type offeree is currently required in step 1 10. then the process returns 
to step 1 06 to update the host application and rewm to step 1 10 to again check until such a change 
the type of force is required. When such a change is required, step 1 12 is implemented, in which 
host computer 12 determines an appropriate host command to send to microprocessor 26. The 

30 available host commands for host computer 12 may each correspond to an associated reflex 
process implemented by microprocessor 26. For example, host commands to provide a damping 
force, a spring force, a gravitational pull, a bumpy surface force, a virtual obstruction force, and 
other forces can be available to host computer 12. These host commands can also include a 
designation of the particular actuators 30 or degrees of freedom which are to apply this desired 

35 force on object 34. The host commands can also include other command parameter information 
which might vary the force produced by a particular reflex process. For example, a damping 
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constant can be included in a host command to designate a desired amount of dampmg force. The 
host command may also preferably ovemde the reflex operation of the processor 26 and mclude 
low-level force values. A preferred command protocol and detailed description of a set of host 
commands is described in greater detail below with respect to Figures 9 and 14. In next step J 14. 
the host computer sends the host command to the microprocessor 26 over bus 24. The process 
then returns to step 106 to update the host application and to return to step 1 10 to check if another 
change in force is required. 

The local microprocessor 26 implements the process branching from step 104 and starting 
v^ith step 116 in parallel with the host computer process described above. In step 116, the 
interface device 14 is activated. For example, signals can be sent between host computer 12 and 
interface device 14 to acknowledge that the interface device is now active and can be commanded 
by host computer 12. From step 116. two processes branch to indicate that there are two 
processes running simultaneously (multi-tasking) on local processor 26. In one process, step 1 1 8 
is implemented, in which the processor 26 reads raw data from sensors 28. As described m step 
88 of Figure 4. processor 26 preferably reads position data and no velocity or acceleration data 
from sensors 28. In alternate embodiments, sensors 28 can include velocity sensors and 
accelerometers for providing velocity and acceleration values of object 34. The sensor dSta read m 
step 1 1 8 can also include other input, such as from an activated button or other control of interface 
device 14. 

In next step 120. processor 26 processes the received raw data into sensor data. As 
described in step 90 of Figure 4. this processing preferably includes the two steps of computing 
velocity and acceleration data from the filtered position data and filtering the velocity and 
acceleration data. Processor 26 can use its own local clock 2 1 to dctemiine the timing data needed 
for computing velocity and acceleration. In addition, a history of previous recorded values, such 
as position or velocity values, can be used to calculate sensor data. In embodiments where 
velocity and/or acceleration sensors are used, the calculation of velocity and/or acceleration is 
omitted. In next step 121. the processor 26 sends the processed sensor data to host computer 12 
and also stores the data for computing forces, as described in the second branch process of 
processor 26. The process then returns to step 1 18 to read raw data. Steps 1 18. 120 and 121 are 
thus continuously implemented to provide current sensor data to processor 26 and host computer 
12. 

The second branch from step 116 is concerned with an "actuator process" in which 
processor 26 controls the actuators 30 to provide forces to object 34. The second branch starts 
with step 122, in which processor 26 checks if a host command has been received from host 
computer 12 over bus 24. If so. the process continues to step 124. where a reflex process 
associated with the host command is selected. Such reflex processes can be stored local to 
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microprocessor 26 in.for example, memory 27 such as RAM or ROM (or EPROM. EEPROM. 
etc.). Thus, the microprocessor might select a damping reflex process if the high level command 
indicated that the damping force from this reflex process should be applied to object 34. The 
available reflex processes are preferably similar to those described above with reference to Figure 
4. and may include algorithms, stored force profiles or values, conditions, etc. In some 
embodimems. steps 118. 120, and 121 for reading sensor data can be incorporated in the reflex 
processes for the microprocessor, so that sensor data is only read once a reflex process has been 
selected. Also, the host command may in some instances simply be a low-level force command 
that provides a force value to be sent to an acUiator 30 (as in the embodiment of Figure 4). m 
which case a reflex process need not be selected. 

After a reflex process has been selected in step 124. or if a new host command has not 
been received in step 122, then step 126 is implemented, in which processor 26 determines a 
processor low-level force command (i.e. force value). The force value is derived from the reflex 
process and any other data required by the reflex process as well as command parameters 
included in relevant host commands. As explained above, the needed data can include sensor data 
and/or timing data from local clock 29. Thus, if no new high level command was received in step 
122. then the microprocessor 26 determines a force command according to the same reflex 
pnxess that it was previously using in step 126. In addition, the host command can include other 
command parameter information needed to determine a force command. For example, the host 
command can indicate the direction of a force along a degree of freedom. 

In step 128. processor 26 outputs the determined processor force command to actuators 
30 to set the output force to the desired level. Before sending out the force command, processor 
26 can optionally convert the force command to an appropriate form usable by acniator 30, or 
actuator interface 38 can perform such conversion. The process then returns to step 122 to check 
if another host command has been received from the host computer 1 2. 

The actuator process of microprocessor 26 (steps 118, 120. 122, 124. 126. and 128) thus 
operates to provide forces on object 34 independently of host computer 12 according to a selected 
reflex process and other parameters. The reflex process determines how the processor force 
command is to be determined based on the most recent sensor data read by microprocessor 26. 
Since a reflex process indicates how forces should be applied depending on the position and other 
parameters of user object 34. the processor can issue low-level force commands, freeing the host 
computer to process the host application and determine only when a new type of force needs to be 
output. This greatly improves communication rates between host computer 12 and intciface 
device 14. 
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In addiuon. the host con,pmer 12 preferably has the ability to override .he reflex operation 
of microprocessor 26 and di.ctly provide calculated or other force values as described alx^ve w.^ 
reference to Figure 4. For example, the host commar^d ca. simply irtdicace a force value to 
sent to an actuator 30. This override mode can also be implememed as a reflex process For 
example, the microprocessor 26 can select a reflex process that instructs it to relay low-level force 
commands received from host computer 12 to an actuator 30. 

Figure 6 is a schematic diagram of an example of a user object 34 that is coupled to a 
gimbal mechanism 140 for providing two or more rota^ degree of freedom to object 34^ 
Gimbal mechanism 140 can be coupled ,o interface device 14 or be provided wuh sensors 28 and 
actuators 30 separately from the other components of interface device 14. 

Gimbal mechanism 140 can be supported by a grounded surface 142. which can be a 
surface of the housing of interface device 14. for example (schematically shown as part of 
member 144). G.mbal mechanise 140 is preferably a five-member linkage that mdudes a 
ground member 144. extension members 146a and 146b. and central members 148a and 148b. 
Ground member 144 is coupled to a base or surface which provides stability for mechan.sm .40^ 
The members of gimbal mechanism 140 are rotatably coupled to one another through the use of 
bearings or pivots, wherein extension member 146a is rotatably coupled to ground member 144 
and can rotate about an axis A. central member 148a is rotatably coupled to extension member 
,46a and can rotate about a floating axis D. extension member 146b is rotatably coupled to 
, ground member 144 and can rotate about ax.s B. central member 148b is rou.bly coupled to 
extension member 146b and can rotate about floating axis E. and central n^ember , 48a .s rotatably 
coupled to central member 148b at a center point P at the intcrsect.on of axes D and E. The axes 
D and E are "noatmg" m the sense that they are not flxed .n one position as are axes A and B. 
Axes A and B are substantially mutually perpendicular. 

Gimbal mechanism 140 is formed as a five member closed chain. Each end of one 
member is coupled to the end of a another member. The five-member linkage is arranged such 
that extension member 146a, central member 148a. and central member 148b can be rotated 
about axis A in a first degree of freedom. The linkage is also arranged such that extension 
member 146b, central member 148b, and central member 148a can be rotated about ax.s B m a 
30 second degree of freedom. 

User object 34 is a physical object that can be coupled to a linear axis member 150, or 
Unear axis member 150 can be considered part of object 34. Linear member 150 is coupled to 
central member 148a and central member 148b at the point of inteisecuon P of axes D and E. 
Linear axis member 150 is coupled to gimbal mechanism 140 such that it extends out of the p ane 
35 defined by axis D and axis E. Unear axis member 150 can be rotated about axis A (and E) by 
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routing extension member I46a. centra] member 148a, and central member 148b .n a first 
revolute degree of freedom, shown as arrow line 151. Member 150 can also be rotated about axts 
B (and D) by rotating extension member 50b and the two central members about axis B in a 
second revolute degree of freedom, shown by arrow line 152. In alternate embodiments, linear 
axis member is also translatably coupled to the ends of central members 148a and 148b. and thus 
can be linearly moved along floating axis C, providing a third degree of freedom as shown by 
arrows 153. Axis C can. of course, be rotated about one or both axes A and B as member 150 .s 
rotated about these axes. In addition, linear axis member 150 in some embodiments can rotated 
about axis C, as indicated by arrow 155. to provide an additional degree of freedom. These 
additional degrees of freedom can also be provided with sensors and actuators to allow processor 
26/host computer 12 to read the position/motion of object 34 and apply forces in those degrees of 
freedom. 

Sensors 28 and actuators 30 can be coupled to gimbal mechanism 140 at the link points 
between members of the apparatus and provide input to and output as described above. Sensors 
15 and actuators can be coupled to extension members 146a and 146b. for example. 

User object 34 is coupled to mechanism 140. User object 44 may be moved in both (or 
all three or four) degrees of freedom provided by gimbal mechanism 140 and linear axis member 
150. As object 34 is moved about axis A. noating axis D varies its position, and as object 34 .s 
moved about axis B, floating axis E varies its position. 

20 Figure 7 is a perspective view of a specific embodiment of an apparatus 160 includ.ng 

gimbal mechanism 140 and other components of interface device 14 for providmg mechanical 
input and output to host computer system 12. Apparatus 160 includes gimbal mechanism 140. 
sensors 141 and actuators 143. User object 34 is shown in this embodiment as a joystick havmg 
a grip portion 162 and is coupled to central member 148a. Apparatus 160 operates m 

25 substantially the same fashion as gimbal mechanism 140 described with reference to Figure 6. 

Gimbal mechanism 140 provides support for apparatus 160 on grounded surface 142, 
such as a table top or similar surface. The members and joints ("bearings") of gimbal mechanism 
140 aie preferably made of a lightweight, rigid, stiff metal, such as aluminum, but can also be 
made of other rigid materials such as other meuls. plastic, etc. Gimbal mechanism 140 includes 

30 ground member 144, capstan drive mechanisms 164. extension members 146a and 146b, central 
drive member 148a. and central link member 148b. Ground member 144 includes a base 
member 166 and vertical support members 168. Base member 166 is coupled to grounded 
surface 142. A vertical support member 168 is coupled to each of these outer surfaces of base 
member 166 such that vertical members 168 are in substantially 90-degree relation with each 

35 other. 
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A dnve mecl,»ism 164 H p.f=«b.y coupled .o «ch vcnical J,.n>bcr IM^ 

Cps«„ dn« n«ch»is™s 164 are deluded i. gimbal mech.n,s™ .40 » prcv^ ™ch..,cal 
^uge «iU.oul inwdacing ftioion mi backlash to U,e system. 

E.,e„sionn,en.ber ,46a is ngidly coupled-oacapstan d™, 170 and is ™,«ed abc„.axis 
A as capstan dmn, 170 is rou^d. Ul<e».se. e««.sion member 146b .s ng.dly coupled u, *e 
Irc^^^drumnOandcanberou^dabootaxisB. Cental d.ve n«mbe, ,4Sa ,s ro.,ab y 

rotaiaoiy coupi connects the two central members 148a and 

point of intersection P of axes A and B. Bearing i // cu.. 

1 48b together at the intersection point P. 

Gimbal .cchanisn, 140 provides two degrees of freedom to an objec. 34 P-«o-^ » °' 
near to tbecenterpointPof rotation. An object at or coupled to point P can be >~ 
A and B or have a combinauon of rota.i«>al movement about these axes. In al«maK 
; l:Len; o.,ec, 34 can also be rotated or translated in other degrees of f«edom, such as a 
linear degree of freedom along axis C or a rotary degree of freedom about axts C. 

Sensors 141 and acmators 143 are preferably coupled to gimbal mechanism 140 to 
provide input and output signals between apparatus 160 and mtcroprocessor 26. ,n the *scnbed 
embodiment, sensors 141 and actuators 143 ar. combined in the same hous.ng as grounded 
0 tr^sducers 174. Preferably, transducers 174a and 174b are bi-direcuonal 

opttcal encoder sensors 141 and active DC servo motors 143. Passive actuators can also ^us^ ^ 
T^e housing of each grounded transducer 174a is preferably coupled to a ventcal suppon member 
^ Z preferably ildes both » actuate .43 for providing force in or otherwtse .nnuencng 
the firs. Lolute degree of freedom about axis A and a sens. 14. '"'^^^^^ 
n obiec. 34 in or otherwtse influenced by the first degree of fre«iom about axts A. A rota, o^ 
^If actuator „4a,scoup,edtoapul,eyofcapstandrtvemechan.m 
output along Ote first degtce of freedom. Grounded tr^tsducer .74b 

glded tlsducer 174a in function and operation. Transducer .74b ,s coupled to t^e th« 
Leal supper, member 168 and is an actuator/sensor which influences or ,s mfiuenced by the 
30 second revolute degree of freedom about axis B. 

The transducers .74a and I74b of the described embodimem are adv»ugeously 
positioned to provide a very low amount of tnenia to Ote use, handling object 34. Transduce, 
maand transducer ,74b are decoupled, meaning Ota. the u^tsducen arc boUtdtrec.., coap.ed» 
ground member 144 which is coupled to ground surface .42, i.e. the ground ^'^'"^ ^ 
35 weight of the mtnsducers, not the user h»>d.ing object 34. The weights and tnenta of the 
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uansducers 174a and 174b a« thus substantially negligible to a user handling and movmg object 
34 This provides a more i^Jistic interface to a virtual reality system, since the computer can 
control the transducers to provide substantially all of the forces felt by the user in these degrees of 
nioUon. Apparams 160 is a high bandwidth force feedback system, meaning thai high frequency 

5 signals can be used to control transducers 174 and these high frequency signals will be apphed to 
the user object with high precision, accuracy, and dependability. The user feds very httle 
compliance or "mushiness" when handling object 34 due to the high bandwidth. In contrast. ,n 
typical prior art arrangements of multi-degree of freedom interfaces, one actuator "ndes" upon 
another acwator in a serial chain of links and actuators. This low bandwidth arrangement causes 

10 the userto feel the inertia of coupled acuiators when manipulating an object. 

Object 34 is shown in Figure 3 as a joystick having a grip portion 126 for the user to 
grasp. A user can move the joystick about axes A and B. The movcmems in these two degrees 
of freedom are sensed by processor 26 and host computer system 12. Forces can be apphed 
preferably in the two degrees of freedom to simulate various haptic sensations. Optionally, other 
15 objects 34 can be coupled to gimbal mechanism 140, as described above. For example, medical 
instruments, such as laparoscopic tools or catheters, can be used to simulate medical procedures. 

Figure 8 is a perspective view of a different embodiment of object 34 and supporting 
mechanism 180 thai can be used in conjunct.on with interface device 14. Mechanism 180 
includes a slotted yoke configuration for use with joystick controllei^ that is well-known to those 

20 skilled in the art. Mechanism 180 includes slotted yoke I82a. slotted yoke 182b. sensors I84a 
and 1 84b. bearings 186a and 1 86b. actuators 188a and 188b. and joystick 34. Slotted yoke 182a 
is rigidly coupled to shaft 189a that extends through and is rigidly coupled to sensor 184a at one 
end of tiie yoke. Slotted yoke 182a is similarly coupled to shaft 189c and bearing 186a at the 
other end of the yoke. Slotted yoke 1 82a is routable about axis L and this movement is detected 

25 by sensor 184a. Actuator 188a can be an active or passive acdiator. In alternate embodiments, 
bearing 186a and be implemented as another sensor like sensor 184a. 

Similarly, slotted yoke 182b is rigidly coupled to shaft 189b and sensor 184b at one end 
and shaft 189d and bearing 186b at the other end. Yoke 182b can rotated about axis M and this 
movement can be detected by sensor 184b. 

30 Object 34 is a joystick that is pivotally attached to ground surface 190 at one end 192 so 

that the other end 194 typically can move in four 90-degree directions above surface 190 in two 
degrees of freedom (and additional directions in other embodiments). Joystick 34 extends 
through slots 196 and 198 in yokes 182a and lg2b, respectively. Thus, as joystick 34 is moved in 
any direction, yokes 182a and 182b follow the joystick and rotate about axes L and M. Sensors 

35 184a-d detect this rotation and can thus track the motion of joystick 34. Actuators I88a and 188b 
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allow the user to experience force feedback when handling joystick 34. Alternatively, other types 
of objects 34 can be used in place of the joystick, or additional objects can be coupled to the 
joystick in yet other embodiments, additional degrees of freedom can be provided to joystick 34. 
For example, the joystick can be provided with a rotary degree of freedom about axis K. as 
indicated by arrow 193. Sensors and/or actuators can also be included for such addiuonal degrees 
of freedom. 

m alternate embodiments, actuators can be coupled to shafts 189c and 189d to provide 
additional force to joystick 34. Acnaator 188a and an actuator coupled to shaft 189c can be 
controlled simultaneously by microprocessor 26 or host computer 12 to apply or release force 
from bail 182a. Similarly, actuator 188b and an acmator coupled to shaft 189d can be controlled 
simultaneously. 

Other embodiments of interface apparatuses and transducers can also be used in interface 
device 14 to provide mechanical input/output for user object 34. For example, interface 
apparatuses which provide one to three (or more) linear degrees of freedom to user object 34 can 
be used. In addition, passive actuators having an amount of "play" can be provided to implement 
different reflex processes. 

Figure 9 is a table 300 showing a number of preferred host commands that can be used in 
the embodiment of Figure 5. where host computer 12 sends high level host commands to local 
microprocessor 26. which implements local reHex processes or reflex processes in accordance 
with the host commands. As discussed previously, low communication rates on bus 24 (Figure 
1) can impede performance, specifically the accuracy and realism, of force feedback, "nie local 
microprocessor can implement reflex processes based on host commands independently of the 
host computer, thus requiring less signals to be communicated over bus 24. Preferably, a 
communication language or force feedback protocol should be standardized for the transfer of 
host commands from the host processor 16 to the local processor 26. Ideally, as discussed with 
reference to Figure 5. the forma* will permit the efficient transmission of high level supervisory 
commands (host commands) to local processor 26 as in step 1 14 of Figure 5. By providing a 
relatively small set of commands and command parameters which are translated into a panoply of 
forces the format further shifts the computational burden from the host computer to the local 
microprocessor 26. In addition, a programmer or developer of force feedback apphcation 
software for host computer 12 is provided with a high level, standard, efficient force feedback 
command protocol. 

In one embodiment, the host command is permitted to include command parameters 
generic to a wide variety of force models implemented by the microprocessor 26 to control the 
actuators 30. For instance, force magnitude and force diitction aie two generic command 
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,^^rs Fore. i^n. o, f<«e mode. applWon time is ano*.r generic — d 
pl^r I. may dso be »iv„u,eous » f»nher define . command parameter or orhe, mpu. 
Z^tl: L L.^.-n. bunon, wben activa^d, can ^ differen. forces or force 

models. 

A prefened embodiment contains two primaty modes or "control paradigms" of operation 
for fc^e feedback interface device ,4-. rate control and position control. Uese 
classification scheme for host commands paran^ri^ed by ^ ^'^'^"^^^'^ Z 
difference between rate cont^l and position control is generally subfle ,0 .he user whtle he or sh 
interacts wtth an application. U,e difference may be profound whet, repres«,«ng fo^ fe *^ 
infonnatton. While cenain force feedback entities may be implemented under both cont™^ 
2« classifying the force feedback commands into two sets can help to avo^ confuston 
l!rg programmers. Some of the commands c. be used as either rate control or postfon 
control commands. 

Exemplaty force feedback commands in accordance with me pteso,. inventi..n wai be 
described belL. The rate control force feedback commands will be discussed r-aonow^J^ 
the positton control commands. Of course, other force feedback commands may be constructed 
in addition to, or as alternatives to. the following sample force feedback commands. 

Rate control refers to a use, object mapping in which dte displacemem of the user objcc, 
34 along one or more provided degrees of freedom is absuactly mapped to motion of a computer- 
simulated enti^ under con^l, such as an airplane, race car. or other simulated "player or p ayer- 
controlled graphic^ object Ra. control is an abstraction which makes force feedback l.« 
inmitive because there is no, a direct physical mapping between object motion and commanded 
motion of the simula,«i computer entity. Nevertheless, many interesting '<"« 
sensationscanbe implemented widtlnratecontrolpar^ligms 7"°" "^'^^^^ 

,0 a user object mapping in which displacement of Ute joyst.ck handle or odjer user mantpu^ 
object di Jtly dicutes displacement of a simulated computer entity, so dta. dje fundam^n^ 
relation between joystick displacements and computer displacements is pr«ent. Thus, most r^ 
control paradigms are fundamentally differem from position control m that the user ol^ect 
Ooystick) can be held steady at a given position but tite simulated entity under conttol ts m motttm 
, t a given commanded veiocity. while the position control paradigm only sJlows the enttty »n^ 
con'ol to be in motion if the user object is in motion. Position control host comm».ds uc 
described in greater detail below wid, respect to Figure 14, while rate conti^l commands are 
described presently wiih reference to Figure 9. 

For example, a common form of rate control is a velocity derived abstraction in which 
S displacement of the user object, such as a joystick handle, dictates a velocity of the stmulatcd 
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compuKr cnnr,. such as a -«hicl. or oto gn.phical objcc. displayed on display screen 20, in a 
I a«d.nl.men,. T^e grea«r *e joysUck handle is n,oved from *e '"^^"^-^ 
*. velocic of tt» co^rolled vehicle or play«.on,roUed graphical objec. Such co«r^ 
^igms are very popular in compmer games where velocity of a spacecraft or r^ car , 
LJi by d. displacem^. of ^ joystick. Like most rate control paradtgrns, veloaty co^ 
allows uJjoysuck .0 be held steady at a given posttion while .he entity under conuol ,s ,n motton 
atagivencommandedvelocity. Other common r«e control paradigms used ,nco,nput.r^n« 
are Leleratton controlled. An acceleration control^, paradigm is termed thmst co tro^ by 
U,ose skilled in the an. While velocity conttol dictates the speed of the enuty un^er conUol th™s 
conaol dictes the rate of change of speed Under thrust control, the ^.ysuck can be sttll and 
centered at zero displacement, yet the commanded computer entity can be m mouon. 

in force feedback schemes, ntte conuol force feedback commands roughly cotrespottd <o 
forces which would be exerted on a vehicle or other simulated emtty controlled by ^ .r^^ 
environment through the force feedback interface device 14. Such forces are ^'^^ 
centric forces For example, tn a thrust control paradigm, a user's stmulated spe«i boa, rm^ 
move into thtck mud, but the user would not directly fee, the mud. However, the use, wouM fe, 
the speed boats engine str^ning agamst a force oppostng the boafs ,r«,»on. These opp^ .ng 
fo Js are relayed ,0 the user through tnterface device 14. Od«r simulated charactensucs or 
objects in the simulated environment can have an effect on the playe-controlled stmuUted enoty 
and thus affect the forces output to the user. 

Herein, rate contK.1 commands an= divided into "condtfons- and ■overlays.- although 
other classifications may be used in alternate embodiments. Condittons se, up a ba.sic phystcd 
model or background sensations about the user object includtng stmulated stiffness, stmula^ 
damping, simulated inettias. deadbands where simulated forces d.mtn.sh. and dtrecuon^ 
, consents dictating the physical model's functionaltty. Multiple conditions may be spectfied ma 
Single command to effeaively supetpose condition forces. Overlays, m con^ ar. forces 
may be applied in addiuon to the conditions in the background. Any nutnber of ovettays «n 
pteLably be provided in addition to condtdon f«ces. A condidon can be spectfted by one 
condition command or by multiple condition commands. 

Descriptions will now be provid«i for several types of forces 302. as referenced in Uble 
300. that can be implemented by microprocessor 26 from host commands. These forces tndude: 
restoring force, restoring spring, vector force, vibration, sluggish stick, 

reflex jolt, and ratchet force. The restoring force, restonng spnng, s,»gg.sh suck, and u,^*^ 
forces are considered condition forces. Tlie veaor force, vibration, wobble, button n=flex jolt, and 
35 ratchet forces are considered overlay forces. 
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The forces 302 shown in table 300 can be implemented with host commands provided by 
host computer 12 to microprocessor 26. Examples 304 of host commands and their syntax are 
shown in uble 300 for each type of force 302. In the described embodiment, host commands 304 
preferably include a command portion 306 and a number of command parameters 308. 
Commands 304 indicate the type of force which the host computer 1 2 is instructing the processor 
26 to implement. This command portion may have a corresponding reflex process which the 
processor 26 can retrieve from memory 27 and implement; this process is described in greater 
detail below. Command portions 306 can be specified in virtually any form in other 
embodiments; in table 300. a command is typically provided in a high-level form, close to 
English, so that the type of force which the command implements can be easily recognized by a 
programmer or software developer. 

Command parameters 304 are values or indicators provided by the host computer 12 
which customize and/or modify the type of force indicated by command portion 304. Many of 
the commands use magnitude, duration, or direction command parameters. Some commands 
include a style parameter which often modifies a force's direction. Other particular command 
parameters are provided for specific forces, as described in detail below. 

For the following preferred rate control embodiments, most of the command parameters 
control different forces in the same way. The magnitude parameter is a percenuge of a maximum 
magnitude corresponding to a maximum force able to be output by actuators 30. The duration 
parameter usually corresponds to a time interval for applying the particular force model. 
However, it is sometimes set to a predetennined value, such as zero or -1. to extend indefmitely 
the force model's application time. The force model would thus remains in effect until the host 
computer 12 provides a new host command with a new force or sends a clear command. The 
style parameter may select a direction in which to apply the force model, and/or a degree of 
freedom along which to apply the force model. For example, valid directions usually include one 
of a common joystick's two axes or a diagonal specified as a combination of the two. Of course, 
the style parameter could specify the force application along any degree of freedom or 
combination of degrees of freedom. Alternatively, separate force commands could be used for 
each degree of freedom or force commands. The style parameter can vary depending on the 
particular force model commanded, as described below. 

Although not listed in Figure 9. all of the described types of forces 302 can have additional 
parameters or incorporate other properties into the listed parameters. A "deadband" parameter 
could specify a size of a region where a force would be small or zero. A parameter can be 
included indicating whether a force is bi-directional or uni-directional along a degree of freedom. 
Note that uni-directional forces can have either a positive or negative sense. For some host 
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S„W.s 310 indica^s a OassmcaUon of .,P« of forc« 302. Forcas 302 a^- 

Wow before Ihe overlay commands. 

Reares lOa-c are graphs mu«iati-g force versus d.splaceme,.. proHles for a resrorirrg 
Figures 10a< >« F P i,Mi^,i„„al, where *e force on 4>e nghl srdc of 

force.Theforcengraph312ofF,gure 10a.sD a.,d the force on the left side 

«,e vertical axis is applied in one direcnon along a degree of fr«dom, an 

of the verucal axis is applied in the "PPOsU^ ^--'-^"^^^^^^ , 

u 1^A «f Pmnrp 10b is uni-direcuonal. rrereraoiy, wnwuiv 
shown m graph 314 of Figure iud un. oarametcr 308 of the 

^storing force is to be applied are also preferably shifted " ^^^ ^^^^ ^ 
an -X" parameter could indicate the "X- degree of freedom, whiles. XY P«^<"'" 

Tre^^orLg force along both X and Y degrees of freedom (e.g., a diagonal restorrng force,, 

.restoringforeeappliedto user ob.c- 3. ^j-^ II^^^^^^^ 
O (or "neutral position") of the user object along a degree of freedom r y 

for a • ystlc. can be the.oysnc.s center ^"J^^l^^^llX L^s 
magnitude of restoring force, specifted by the magnitude command P"-'"^- ^ 

forces the use, object back to the origin posiuon when the object ,s m rang. 3 16. Th. restorrng 
O Z dimi ishes o, vanishes as the object nears and reaches the ongm ^.uon. "Ite 
a l^ng force-s direction can be automadcally eont^lled by the local mtcroprocessor 26. 

,n Figure 10c, the restoring force is shown similarly to the fotce in Figute 10a. ex«pt 
appL L is about .ro ,n an extended region 31g. aboutthe origin ^''^^^^IZ 
.„ow!asaMeadband^andallowstheusertoh„eso„free.^^^ 

distance around .he origin before for«s '^^^'^' J^^'^l^ ™d 
,5 applied resroting force can be a value included, for example, as a separate 
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parameter, or. alternatively, as part of the style parameters 308 of the ftstoring force host 
command. 

A restoring force sensation can be very ably applied in a rate control paradigm to the 
situation of hitting a wall or some other obstmction while controlling a simulated vehicle. The 
restoring force indicates a resistance against commanding a velocity in a direction of motion. This 
force drops off when the user object is renimed to the origin position because the user is no longer 
commanding a velocity in the direction of motion. If there is no obstruction in the reverse 
direction, the restoring force would be unidirectional. 

Figures 1 la-1 Ic are graphs illustrating force versus displacement profiles for a restoring 
spring force. Rather than maintaining a constant magninide over its positive or negative 
displacement, as provided by the restoring force of Figures lOa-lOc. a restoring spring force 
varies linearly over an appreciable portion of the user object's displacement, and is proportional to 
the object 34 s disunce from the origin position O. A restoring spring force applied to the user 
object always points back towards the neutral position along a degree of freedom. In Figures 1 la- 
1 Ic the restoring spring force reaches its maximum at maximum displacement of object 34 from 
the origin position O. Graph 320 of Figure 1 la shows the bi-directional case, and graph 322 of 
Figure lib shows the uni-directional case. A deadband specified by a deadband parameter >s 
provided about the origin position, as shown in graph 324 of Figure 1 Ic. 

The parameters for the restoring spring force can. for example, be substantially similar to 
the parameters for the restoring force as described above. Alternatively, instead of a magnitude 
parameter, the restoring spring force can have a spring coefficient parameter to describe a desired 
• stiffness " of the object 34. The spring coefficient parameter can be used in well known equations 
to calculate the force on the user object. Either the coefficient or magnitude parameter may be 
used. 

The sluggish force creates a damping force on user object 34 having a magnitude 
proportional to the velocity of the user object when moved by the user. An example of this type 
of damping force is described above with respect to step 82 of Figure 4. The degree of 
"viscosity" of the sluggish force can be specified by a viscous damping coefficient included as a 
command parameter in the host command. Since the sluggish stick force depends directly upon 
30 velocity, the coefficient command parameter can be expressed as a percentage of a maximum 
damping coefficient, and replaces the magnitude parameter of previously discussed host 
commands. The style command parameter for the sluggish host command can include the 
specified degrees of freedom to apply the sluggish force, as well as a uni-directional or bi- 
directional indication. The sluggish stick force is particularly suited for rate control applications to 



25 



41 



wo 97/12357 



PCTAJS96n5373 



Simulate controlling, for example, a veiy heavy vehicle that is poorly responsive to the movement 
of the user object. 

The unstable force creates an inverted pendulum style instability. Alternatively, the 
unstable force is modelled on a spring having a negative spring constant (an unstable or diverging 
spring). A force is applied to the user object in a direction away from the object's origin position 
and is increased as the user object is moved further away from the origin position. This creates a 
force that makes it difficult for the user to bring the object to the origin position. The command 
parameters for an unstable host command can include similar parameters to the restoring forces 
described above; for example, a command parameter indicating the percentage of maximum 
degree of "instability" can be provided, where the instability can be defined in terms of a 
maximum output force. This force can be used as another vehicle-related sensation, and could 
replace a restoring spring force when, for example, a simulated vehicle guidance control is 
damaged. The instability would typically make a computer game very hard to play. 

In alternative embodiments, the condition forces described above can be commanded 
using only one host command with a number of parameters to control the characteristics of the 
condition forces. For example, a host command such as 

COND_X (K+. K-. DB. B+. B-. N.Offset. Sai+. Sat-, m) 

can be sent to microprocessor 26 from host computer 12. This command specifies certain 
physical parameters of a model of the user object in one degree of freedom. The K parameters 
indicate a proportional stiffness for displacements of the user object in two directions along a 
degree of freedom. The DB parameter indicates the deadband range as a percentage of a 
maximum allowed deadband distance. The B parameters indicate a velocity proportional damping 
for the velocity of the user object in two directions along a degree of freedom. The N.offset 
parameter can be specified as the offset from the modeled neutral position of the springs (defined 
by the K parameters). The Sat parameters indicate the maximum (saturation) allowed force value 
for displacements of the user object, expressed, for example, as a percentage of the maximum 
possible force. The m parameter indicates a simulated mass of the user object which can be 
applied in the physical model for computing gravitational or inertial forces on the user object, for 
example. A condition command as provided above can be used for each provided degree of 
freedom of user object 34; for example. COND.X can provide the condition forces in the degree 
of freedom about the x-axis. The command can implement the restoring force, restoring spring 
force, sluggish force, and unstable force by adjusting the various command parameters. 

The condition commands can be provided in the background while overiay commands are 
applied in addition to or "over" the condition forces. For example, a sluggish damping force can 
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be provided as a background force to the user object, and a "jolt" overlay force can be commanded 
over the sluggish force to provide a quick, jerky motion on the user object for a few seconds. Of 
course, overlay forces may also be applied exclusively when no other forces are bemg applied, or 
may cancel other previously-commanded forces if desired. The example overlay forces shown in 

5 Figure 9 are described below. 

Figure 12 is a graph 326 illustrating a vector force model. A vector force is an overlay 
command, and thus can be applied in addition to die condition forces described above. It is a 
general force applied to the joystick in a given direction specified by a direction command 
parameter. The direction command parameter can be provided, for example, as an angle in the X- 
10 Y plane for a two-degree-of-freedom interface apparatus. As for many of the condiuon force 
commands, the magnitude of the veaor force can be specified as a percentage of a maximum 
magnitude. Figure 12 shows a two-dimensional representation of the vector force in an example 
direction in the X-Y plane of a user object having two degrees of freedom. 

Figures 13a- 13b are graphs illustrating force versus time profiles for a vibration force. 

15 Figure 1 3a is a graph 328 showing a bi-direciional vibration force while Figure 13b is a graph 330 
showing a uni-dircctional vibration force. The vibration command shown in Figure 9 accepts 
magnitude, frequency, style, direction, and duration command parameters. Tht frequency 
parameter can be implemented as a percentage of a maximum frequency and is inversely 
proport.onal to a time interval of one period, Tp. The direction command parameter can be 

20 implemented as an angle, as described above with reference to Figure 12. The style parameter can 
indicate whether the vibration force is uni-dircctional or bi-directional. In addition, a duty cycle 
parameter can be provided in alternate embodiments indicatmg the percentage of a time period that 
the vibration force is applied. Also, a command parameter can be included to designate the 
"shape" or profile of the vibration waveform in the time axis, where one of a predetermmed 

25 number of shapes can be selected. For example, the force might be specified as a sinusoidal 
force, a sawtooth-shaped force, a square waveform force, etc. 

A wobble force paradigm is another overlay force that can be commanded by host 
computer 12. This force creates a random (or seemingly random to the user), off-balance force 
sensation on the user object. For example, it can simulate an erratic control for a damaged vehicle. 

30 Tlie magnimde, duration, and style command parameters can be similar to parameters for the 
above host commands. The style parameter might also specify a type of wobble force from a 
predetermined list of different types. The wobble force can be implemented using a variety of 
methods. For example, a preprogrammed "force profile" stored in memory can be implemented 
to cause a force sensation that seems random. Or, an equation can be used to calculate a force 

35 based on a sine wave or other function or a random result. 
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THe jolt force is typically a short, high magnitude force that .s output on the user object, 
and can be used, for example, to notify the user of an event or simulated object .n the computer 
environment, m jolt force can be used as an overlay force which can be felt in addiuon to any 
condition forces in effect. Typical parameters include the magnitude of the ^orcof ^c^M the 

5 duration of the jolt, and d.rect.on(s) or degree(s) of freedom in which the jolt is apphed. wh.ch can 
be specified as an angle or particular degrees of freedom, m magnitude command parameter 
preferably specifies the magnitude of the jolt force in addition to (above) any other cond.uon or 
overlay force magnitudes, i.e.. the magnin.de is a differential magnitude "above" the steady state 
forces. Thus, the acmal magnitude output by acmators 30 may be greater than the jolt force 

10 magnitude. 

The button force is not an actual force but may be used as a command to trigger other 
forces when an input device 39 is activated by the user. In many game situations, for example. « 
may be advantageous to trigger a force as a direct response to pressing a button or other mput 
device 39 on the interface apparatus 14 rather than generating the force from a host command after 
,5 processing the pressed button on the host computer 12. The other forces tnggered by the pressmg 
of the button can be specified as a command parameter in the button command; altematrvely. a 
specific button command can be provided for each type of force. 

For example, a common force to use in conjunction with a button command is the jolt 
force A specific command, e.g.. BUTTONJOLT. can be provided to cause a jol. force 
20 whenever a specified button is pressed, and which includes button and jolt command parameters. 
Alternatively, a button command with a JOLT command parameter may be implemented. When 
the button joh command is received by microproces.sor 26. the microprocessor can run a button 
check as a background process until commanded to tenninate the button background process. 
Thus, when the microprocessor 26 detemiines that the user has pressed a button from the sensor 
25 data, the jolt force can be overiaid on any existing forces that are output. 

The Sutton command sets up the microprocessor 26 to output a force when the other input 
device 39 has been activated. The button command may accept a number of command 
parameters including, for example, button and autofire frequency parameters (in addmon to any 
command parameters specific to the desired force to be output when the button is pressed), m 
30 button parameter selects the particular button(s) which the microprocessor 26 w.ll check to be 
activated by the user and which will provide the desired forces. For example, a joystick may have 
multiple buttons, and the software developer may want to provide a force only when a particular 
one of those buttons is pressed. A duration parameter can determine how long the jolt lasts after 
the button is pressed. The "autofire" frequency parameter designates the frequency of a rcpeatmg 
35 force when the user holds down a button. For example, if the user holds down a particular button, 
the microprocessor can automatically repeat a jolt force after a predetermined time mterval has 
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passed after tf,e user firs. press«l Ae button. •n» autofire p««tKtcr cm >lso optionally dcsignau: 
rr.hc a^tofire fcan.. is being used for a p»iclar bunon and *e desired »n,e tntet^al 
before the repeating forces arc applied. 

other nue control commands not shown in .he table of Hgure 9 can also be implemented. 
For example, i, acmators 30 « passive acn..o., a -ratche,- force can be provided by send,ng a 
ratche, command and appropriate command paramcers. This command can s,mul..e ^ 
obsmtcion which causes, for example, a user-controlled vehicle to str«n in a pven deg« of 
freedom Thus, a force may be applied when .he user moves thejoysiick in one direct,on, then no 
force is applied when U,e user moves .he joysticlc in *e opposite direction, and force ,s agatn 
applied when .he joys.ick is moved in .he original ditecUon. This simulates an obstmcnon force a. 
any retraction point, like a mtchet. The style parameters for such a command can md.cate a fixed 
obstruction or a ratchet-style obstniction. 

This concludes the description of rate control commands and force models. 

Figure 14 is a table 332 showing a number of preferred position control host commands 
5 that can be used in the embodiment of Figure 5. Herein, "position control" refers to a mappmg of 
a user object in which displacemem of the joystick handle or other user object d.rectly dictates 
displacement of a computer-simulated entity or object. Hie mapping can have an arbitrary scale 
factor or even be non-linear, but the fundamental relation between user object displacements and 
computer object or entity displacements should be present. Under a position control mappmg^ the 
:0 computer-controlled entity does not move unless the user object is in motion; a static user object 
dictates static commands to microprocessor 26 from host computer 12. 

Position control is not a popular mapping for traditional computer games, but may be used 
in other applications such as medical procedure simulations or graphical user interfaces. FosUion 
control is an intuitive and effective metaphor for force feedback interactions because it is a d.tect 
25 physical mappmg rather than an abstract control paradigm In other words, because the user 
obit experiences the same physical manipulations as the entity being controlled within the 
computer, position control allows physical computer simulations to be directly reflected as 
.alistic force feedback sensations. Examples of position control in computer environinents 
might be controlling a paddle in a pong-style tennis game or controlling a cursor in a windows 
30 desktop environment. 

Contrasted with rate control's vehicle-cenuic forces, position control force feedback 
roughly corresponds to forces which would be perceived directly by the user. These are •'user- 
centric" forces. For example, a paddle displayed on display screen 20 and directly controlled by a 
user might move through simulated thick mud. Via the force feedback interface device 14. Ihe 

45 



PCr/US96/15373 

WO 97/12357 

• .K -nc fnrce associated with movement through a viscous solution, 
user would perceive the varying force assoctai 

Corresponding to the realistic physical situation, the force v^es with the spee 
joystick (and displayed paddle) and orientauon of the paddle face. 

Descriptions will now be provided for several types of position control forces 334^ ^ 
3 „r 33. can . implemented ^^^^^^ ^ —1:: 
These forces mclude: vector, groove, divot, texnire, 

Manyofthee.amp..33eof ho.c— As ^ - - 
style paiamaers as discussed with reference <m r 
do. co™.a„ds, command pa,an«.ers of d,= same ^ ^^^^ J 

^A. U/iu/Pv^T the duration parameter is rypicauy noi u^cu ^ 
,„ ,0, differen, ' ~ H J„„ds. since d,e du,a.io„ of .he posidon 

-tsrrmrarrr:::::— ^ 

15 can be used. 

P„fe.ed paramemzauons tordescnbed posUion control commands ^ summari«d m 

H.. " : forces .s. - ^ — 1 

deadband paramelers. or incorporate other propen.es mto the p 

Similar to the host commands shown in Figure 9, — ^^J^'^^^;'"* 

command ponion may have a correspondtng P'^^^ J^^ ,„ „y 

from memory 27 and implement. Command pontons 338 can be spectte 

in other embodiments. 

A vector force is a general force having a magnitude and direction. Refer to Ftgure 12 for 

Figure 15 is a gntph 342 showing a force versus dtsplacemem relaUonship for a groove 
35 of the user object when the host command was recetvcd. Alternatively, 
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„ ,^ be aedfrf from a command parameter along one or more degrees of 
C:r."Cr^~..on«ve.e.«ro.iec.o„, o, . groove, a re...„s .rce . 

applied. 

- — <— 'Tr:r:rrgrr:nr;:rz':e 

TZ " " microprocessor 26 would receive a groove command havmg a 
shown as d,srance " „ coprocessor de«c,s user o„e« moving ourside Uus 

snap disonce magnimde. When U>e .n.crop j^ptomed equally 

snap d,s,ance. i. Iun,s off Ore groove forces. Thrs '"^P""" 

J by .he hos, computer 12 sending a dearcommand o ™m off ^'^^ ^ 

ean also he provided .0 allow d,eus„obJe«^mo. r^^-^^^^^^ P^^^^^ ^ 

specified wid, a deadha^l command ^'^^ '^"^ Zo. J,,, ,„rtzo„.ai. venical, 
onenuu^ of >he groove along one or mor^ ^^"^ , „o„ 

diagonal). f->-'"-<^-^'^'^'^'''''^^l''^^J^ZIc^ feel groove forces 

hars in windows. A user moving a cursor in '^'^^Zl'^ Z^^^^^ gives *e 

ntoving d.e cursor and user object toward the middle of the scro 

user room to move .he cursor Within the scroll bar region. The '"^P °" ^^'l 

free .he cursor/user objec. from forces once Ote cursor ,s moved out of the scroll bar regton. 

A divo. is essentially two (or more) orthogonal grooves that provide restoring forces in 
A aivoi IS esicii y «nsation of a point detent along a given 

more than one degree of freedom. Th.s provides the °' P 

; feahire of Ute groove can be provided for the divot command. 

, „„ described above with reference to Figure 

A texture force simulates a surface property, as descnoeo ao 

A texture 1 „,,„.,„,„(« oDOOsed to vibration, a time varying force) dial 

4. A texture is a spatial y ^'»"'\<°'"'^ °l^^ , 5„,j„g. Other types of 

rroir-^rs^Trsetianjp:^.^ p-^^^^^^^^^^^^^ 

and a style, "n^ magnimde specifies *e amount of force apphed o .H - "^^'^ ^ 
-bump- of the graUng, The gn. is basical., .he spacing be.we=n each o W g ^ 
„ s-y-c — dpa,ame.erca„s^fy«.cHen.aUon o ~ ^ 
specify a horizonul grating, a vertical graung. or a diagonal gmttng (or supeip 
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gnxinis). Fu„.»nno«.*cs.ylcpar™.«rcan.p«ifyifU««™-lsf=l< b,-d,«c„on3ll.v o, urn- 
di««ioo»l)y >lont = degree of freedom. Al.en,aively. additional command pa«me>ers can be 
pravided .0 co™«,l ■he position of the "bumpr of the texmte force. For example, tnfonnauon 
cm be included to instmct d>e distance between bumps to van, exponenttaily over a dtstance. or 
va,7 according to a specified fomtull Alternatively, me texmre spacing could vary randomly In 
yaother embodiments, the command parameters can specify one of several available standa«) 
texture patterns that microprocessor 26 can retrieve from memory. 

A barrier force, when commanded, simutates a wall or other obsnucuon placed a. a 
location in user objea space, and is described above with reference to Figure 4. The host 
command can specify the hardness of the batrier (magnitude of the force apphed). the ocauon of 
the barrier along .he degree of freedom, and the snap distance or thtckness o the bamer 
Horizonul barriers and ve,*al batriers can be provided as separate host comrnands. ,f c^stred 
AS indicated in graph 346 of Figure 16. a barrier force only has a ftn.te thtckness. T^e fo ce 
increases steeply as the user ol^c is moved closer into Ute bamer (past potnt B). The s^P- 

: through distance deftnes the size of the regton where the banker is feh by the user. If the user 
object is moved into a barrier, and then is moved past the thickness of the baMer. the banter force 
is turned off. The barrier force can act as a hard obstruction, where the microprocessor provides 
maximum force magnitude to the user objec, 34, or as a bump or softer barrier, where a smaller 
force magnitude is applied (as specified by the magnitude command parameter). T^e bamer can 

„ remain for an extended period u„le« removed or moved to a new location. Multiple barriers can 
also be provided in succession along a degree of freedom. 

Altematively. the barrier foi^e can be provided by sending a bos, command having only 
two command parameters, hardness and location. The hardness parameter can specify the heigh, 
and slope of the resisiive foice. As shown in graph 348 of Figure 1 6, the user o.,=c. can move 

« from left to right along the distance axis. The user object feels a resistive force when h,«ing the 
barrier at poim B. After the user object has been moved to point S (the .snaH-tance), the force ,s 
applied to the user object in die opposite direction (a negative magnitude force which decmas« 
as the user object is moved in the same dtrection. litis simulates a bump or htU. where the fon:e 
is resisiive u„,il the user object ,s moved to the lop of the bump, where the forte becomes an 

30 assisting force as the object is moved down the Other side Of the bump. 

A force field type force attracts or repulses die user object with respect to a specific 
position. This force can be defined by command parameten such as a field mapitude and die 
specific field origin position which the force field is applied with respea to. A sense par^Kr 
caTbe included to indicate an attractive field or a repulsive field. For example, the force field can 
„ be an atm«ive field to simulate a force of gravity between the field otigin positton at-d a ,«e,- 
controlled cursor or object. Although the field origin positton can be thought of .s . 
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gravitational mass or an electric charge, the attractive force need not depend on the inverse square 
of displacement from the specific position; for example, the force can depend on an .nverse of the 
displacement. The attractive force field also attempts to maintain the user object at the field ong.n 
position once the user object has been moved to that position. A repulsive field operates similarly 
^cept forces the user object away from a specified field origin position. In addition, ranges can 
be s^cified as additional command paramete,, to limit the effect of a force field to a panicular 
disunce range about the field origin position. 

Figures 17a-17i are diagrammatic illustrations of a "paddle" computer object 350 
interacting with a "ball" computer object or similar object 352. These computer objects can be 
displayed on display screen 20 by host computer 16. -Die force interactions between the ball and 
paddle can be controlled by a software developer using a host command, as explained below^ In 
the described example, paddle object 350 is controlled by a player by a position control i«radigm 
such that the movement of paddle object 350 is directly mapped to movement of user object 34. 
In alternate embodiments, ball object 352 or both objects can be controlled by players. 

Figures 17a-17h show how paddle object 350 interacts with a moving ball object 352 as 
ball object 352collides with the paddle object. In Figure 17a. ball 352 first impacts paddle 350^ 
Preferably, an initial force is applied to user object 34 in the appropriate direction. In Figures 17b 
and 17c, ball 352 is moving into the compliant paddle or "sling". Preferably, a simulated mass o 
ball 352 is felt by the user through user object 34 which is appropriate to the simulated velocity of 
the ball the simulated compliance of the paddle, and the strength/direction of simulated gravity. 
These parameters can preferably be set using a host command with the appropriate parameters. 
For example, the following host command can be used: 

PADDLE (B.mass, B.vel.x, B.vel^. Gravity. Sense, Compliance.X. Compliance.Y) 

where the command parameter B_mass indicates the simulated mass of the ball. B vel.x and 
B vel_y are the velocity of the ball, gravity is the strength of gravity, sense is the direct.u.. of 
gravity, and Compliance.X and Compliance.Y an. the simulated compliance or stiffness of the 
paddle object 34. Other parameters can also be included to control other physical aspects of the 
computer environment and interaction of objects. 

In Figure 17d. the ball has reached a maximum fiexibility point of paddle 34 and can no 
longer move in the same direction. As shown in Figures 17e through 17g. the ball is forced ,n the 
opposite direction due to the compliance of the paddle. In addition, the user may preferably exert 
force on user object 34 to direct the ball in a certain direction and to add more velocity to the ball s 
movement. This allows the user a fine degree of control and allows a significant applicauon of 
skill in directing the ball in a desired direcUon. m force feedback paddle is thus an improved 
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compo«n> of "pong- type and ote .imi.. v,dco games. In addiuon. *c paddle 350 ca. 
opUoMlly flex in the opposite diieclioo as shown in Figure Hh 

Aschematic model of the forces intencungtatween ball 352 and paddle 350 U shown in 
Figure Hi. A spdng forte indicaed by spring comta.. K is provided in both degrees of freedom 
5 X and Y .0 indicate .he springiness of the paddle 350; g is a gravKy direction. In addmon. a 
iTp-nl force indicate! ^ damping constat B is also provided to slow Ote ball 352 down once , 
contact p«idlc 350. spring and damping forces can also be applied m one degree of 
freedom. 

TOe paddle control algorithm is a dynamic algorithm in which microprocessor 26 
,0 computes interaction forces while a ball compresses the paddle and then releases from *|e 
The paddle con^mand is sen, b, host computer 12 when the ball contacts *e paddle. Th^ 
command reports ball location to the host computer so that the host can update graph,., d, layed 
on display screen 20 durrng d,e infraction period. In presently preferred "^^'^ 
updates only need to be provided at about 60 Hz to d« hos,. since most d.splays 20 can only 
,5 dsplayatthatrate.However..heforcesshouldbecomputedandou,p«,atabo»t500Hzormo« 

,0 pn^vide a realistic -feel" to *e interacdon. Tltus ^ local nticop'ocessor - -mpu e *e 
foL quickl, while occasionally reporting the sensor readings of the paddle to U,e host at a 
slowerL Other typesofvid^gameor simulation interactions c^ also be commanded w,,^ 
high-level host command in a similar fashion. This concludes the descripuon of pos,uon comrol 
20 paradigms. 

In addition, a clear command is preferably available to the host computer. This command 
include aparameterspecifyngpanicular degrees of freedom and allows the host computer to 
cancel all forces m the specified degrees of freedom. This allows forces to be removed before 
other forces are applied if the programmer does not wish to superimpose the forces. 

Also, a configuration host command can be provided. This command can initially set up 
the interface device ,4 to receive particular communicat.on parameters and to specify wh.ch mput 
and output will be used for a particular appHcation. e.g. the host computer can mstiuct local 
microprocessor 26 to repon specific information to the host computer and how often to report the 
information. For example, host computer 12 can instruct microprocessor 26 to report posmon 
30 values fn.m particular degrees of freedom, button states from particular buttons of interface dev.ce 
14. and to what degree to report errors that occur to the host computer. A "request .nfonnatton 
command can also be sent by host computer 12 to interface device 14 to receive .nformauon 
stored on the interface device 14 at the time of manufacwre. such as serial number, model 
number, style infonnation. calibration parameters and infonnation. resolution of sensor data, 
35 resolution of force control, range of motion along p«>vided degrees of freedom, etc. This 
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infonnation may be necessary to the host computer so that the commands it outputs to the iocal 
processor 26 can be adjusted and customized to the particular type of interface device 14. If the 
USB communication interface is used, other information necessary to that mterface can be 
provided to the host upon a request command, such as vendor identification, device class, and 
power management information. 

In addition, the above described forces can be superimposed. The host computer can send 
a new host command while a previous host command is still in effect. This allows forces apphed 
to the user object to be combined from different controlling commands. The microprocessor 26 
or host computer may prevent certain commands that have contradictory effects from bemg 
supenmposed (such as a restoring force and a restoring spring). For example, the latest host 
command sent can override previous commands if those previous commands conflict with the 
new command. Or, the conflicting commands can be assigned priorities and the command w.th 
the highest priority overrides the other conflicting commands. 

It should be noted that the high-level host commands and command parameters described 
,5 above are merely examples for implementing the forces of the present invention. For example, 
command parameters that are described separately can be combined into single parameters havmg 
different portions. Also, the distinct commands shown can be combined or separated m different 
ways, as shown above with the example of the condition command for providing multiple rate 
control condition forces. 

In addition to common interface devices with one or two rectangular or spherical degrees 
of freedom, such as standard joysticks, other interface devices can be provided with three or more 
degrees of freedom. When the third degree of freedom is about an axis along the stick itself, 
those skilled in the art call it -spin" or "twist." Each degree of freedom of a user object can have 
its own dedicated high-level host command. By independently associating high-level host 
25 commands to each degree of freedom, many possible combinations of position control, rate 
control, and other abstract mappings can be implemented wUh mterface devices. 

For example, for a common joysuck with two degrees of freedom, a computer game 
might allow the joystick to control flight of a spacecraft. Forward-backward motion of the 
joystick handle might implemem thrust control to dictate an accelerauon of the spacecraft. U^ft- 
30 right motion of the joystick might implement direction control to dicute an angular velocity of the 
spacecraft's trajectory. This particular thrust-direction paradigm is particularly popular m current 
games, but there are many variations. For example, in a flight simulator, the forward-backward 
motion of the joystick might control the pitch of an aircraft while the left-right mot.on might 
control roll of the aircraft. In a driving game, the forward-backward motion of the sttck might be 
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a rate cor^trol mapping to an acceleration of the car. while the left-right motion might be a posu.on 
control mapping to a location of the car across a span of road. 

Muhipk control paradigms may also be mixed in a single degree of freedom. For 
example, a joystick may have position control for small deviations from the ongin in a degr«^ of 
5 freedom and rate control for large deviations from the origin in the same degree of freedom. Such 
a mixed control paradigm can be referred to as a local position/global rate control paradigm. 

Figure 18 is a block diagram illustrating an example of a functional microprocessor 26 
implementation 380 of the present invention for processing the host commands and command 
pimeters to output forces to user object 34. Implementation 380 is preferably provided on the 
0 microprocessor 26 using instr.ct.ons stored in memory 27. TU. -e of program - 
perform operations on a microprocessor is well known to those sk.lled m t^e an. and ca. be 
Led on a "computer readable medium." Herein, such a med.um includes by way of example 
memory 27 such as RAM and ROM. magnetic disks, magnetic tape, optically readable med.a 
such as CD ROMs, semiconductor memory such as PCMCIA cards, etc. In each case, the 
,S medium may take form of a portable item such as a small disk, diskette ^ 
n.ay take the form of a relat.vely larger or immobile item such as a hard d.sk dnve. Prefe^bly, 
various subprocesses 382. 384. 386. 387, and 388 run in parallel on microprocessor 26 to 
optimize responsiveness of the force feedback interface device 14. These processes are also 
referred to as "processors" herem. Vanous parameters and data are shared by the subprocesses of 
20 implementation 380 in a preferred embodiment. 

Throughout the following d.scuss.on of implementation 380. parameter sets or parameter 
pages can be stored to speed computation and appHcat.on of forces. Herein, parameter sets w.l be 
considered synonymous with parameter pages. Rather than reading, storing and applymg host 
commands and command parameters (and/or other parameters) as soon as the command « 
25 received, all or some of the commands and parameters def.ning a force environment may be 
stored and grouped into parameter pages stored in memory 27. This force environmem can 
describe particular forces that may be quickly read from the parameter page. When the 
appropriate force environmem is required by the host computer, the microprocessor can retneve 
the parameter page from memory. As with page swapping in video display systems. 
30 implementation 380 could then use active pages for a currem force environmem and hidden 
pages for command/parameter sets under construction. In addition, preset or predefined foic 
environments can be retneved. which a. standardized force environments that are provided with 
interface device 14 or which can be loaded onto interface device 14 from the host computer. In 
the preferred embodiment, a stored parameter page would include force parameters and reportmg 
35 parameters, which are internal microprocessor parameters that are denved from the host 
command and command parameters and which are discussed below. 
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Host communication and background process 382 maintains communication between the 

..croprocessor26andthehostcomputcrI2. "ost communication an«c.^^^^^^^ 

receives high-level host commands and command parameters from the host 12 and sends 
receives nign ^^^^ ^ reportmg process 

data to a command process 384. Process 382 also recci c 

^87 described below Process 382 directly iclays information received from process 387 tne 
387 descried bel^. communication "switchboard" between the 

host 12. Essenually, process 382 act^ process 382 (or process 384) manages 

microorocessor 26 and the host computer 12. Preferably, process f ^ ^ . r „ 

microprocessor commands and data from 

inl«face and Cher inttrfaces with highi:ororoumcal,on rales. 

The command proc«s 384 processes i,«oming hi|h-lev.l host commands ^ command 
paramel^s Z a>e 1 12 and .ransmiued via .he hos, communica.ion and backgr<H.nd proces 
rB::.nlincomingc„mm«-ds.d.comma„dproc.ss3S4se.srep^^^^^ 

force feedback conm.. paramerers. "H^se types of parameters '^'^^ ^'^^^ ^^^ 
microprocessor 26 and are to be distinguished from the command parameters 308 tmluded tn 
Wgh-l vei host command sen. b, the host. 1^ int«na, parameters are *J 
clland parametet, and may, in some instar«es, be identical to dte command parameter., as 

explained below. 

The reporting parameters are internal parameters that specify to the microprocessor 26 
„K,ch partJar data 1 at what rate to repot, to hos. computer .2. m «po.t.ng paramet^ 
:I o example, specify whedter .o repon posittons or veloctties of user object 34 for pantcular 
degrees of freedom, a communication speed, or whether and in what way etrors .= potc . Th 
re^tUng parame«rs are denved from ttte conftprration commands recetved "J^ 
computer Uandarep^videdtodte stams upda« process 386 and reporrmg P-/" " 
"^ess 387 knows which in.orma.ion to repon to the hos, computer ,2 v,a Utc hos. 
communication and background process 382. 

Force feedback control parameters ( force parameters") »e i^emal parametet. ma, a« 
provided or updared by cor^and process 384 and are used by force algor,d,m ""P"""™ >^ 
actuator c„n.o. process 388. The force parame«,s a., derived from *e comman pa«^e« 
308 included .n L received host command. Command proce. 384 
parameters and updates the internal force parameters so dtat the other processes 88 and 38^^«n 
access dte most force parameters. This process of providing/up<iat,ng fotce parameters 
implementtd by process 384 is described below wi.h reference to Figure 19. 

T^e status update process 386 receives reporting parameters from the 'o™™"" P-^-f 
> 384. bL on the parameter, received, pr^ess 386 reads sensors 28 ».d clock 29 and stores 



53 



PCT/US96/15373 

WO 97/12357 

sensor .^ding his,on« and Un,ing hls.ones. Prccs 386 .so can compmc 
veloci,, or .cccler«,on vines, deHved from sensor posiuon dara, ,he sensor ^J^Tl '^Z 
^ o eombinadons of Uus dau. Herein. ^ .er. "sensor da." refers ^^^'^^^ 
I^y fron, *e sensors (sensor read.ngs, and/or values denved frorn U« -nsor «a^ng. 

::!:::.Tr;:od of^r i-^jLL of «nnns da. PeHo^e... .ep^S P-s 
^T^^rarrovided and s.or«i by process 386 ,or process 3S6 could se»i *e dau » prc«.ss 
3 CT t^c sensor and ,Wng dau is also "sen.- .o a force a.goHe>n, compuuuon and 
process 38S. T.e .enn -sen.- or -received- herein refers .„ P-^J^^^ 
da,a .l,a. anoto process cvemualiy receives. Tl« acmal imptemenumon .o send and ,ece,ve da.a 
can va^ ,n differen. embodimen,s. For exan,p,e. ^ sending process .nay 
"red dau in memory and 0.e receiving process can rerHeve d« da. from memory a. ..s 
own rate. 

process ^b^. e implemented by reporting process 387 is 

387 from force computation process 388. Tlie process impicmcn , r 

, u ,,^Fiou^e 21 In aliemaie embodiments, reporting process 

described in greaterdetail with respect to Figure 21. in aiiem ,he host at a 

387 can be merged with background process 382. for example, if reporting data to the host 
regular rate (in "streana" mode). 

Force algorita comp«.a.ion and ac^a.or con.o. process 388 .ses force P--""^ 
sensor da.a from .he command process 384 and ,he s,a.us upda,c process 386 .o -"P"< 

pp.ied.ouserobiec.34. TTe force param=.ers are denved from command «' 
cHL vaHous foie models, as described in de.i, above. Process 388 compu,es a r«u,»,. 
force .0 be applied .o ac.ua,ors 30 by combining effect of all force models m effca 

„ sbould be emphasi^d 0,a. .he processes 382. 384. 386. 387. »,d 388 wirbin d,= 
implemenu.ion 380 in Figure 18 preferably nm in parallel on .he "^'"^^^^^^TJ^'^ 
muUi-usking environmen.. Running all diese processes se,uen.,ally would drama.,ca«y slow *,e 
0 force feedback response .o user manipularion of .he user objec. 34. 

The implemen,a.ion 380 shown in Fiprc 18 is ,n.e„d«l as an example of a way ,o 
Ure various subprocesses of microprocessor 26 ,n.o logical divisions. 
various od,er ■mplemen.a.ions can be provided .o join or separa« some or all of *e descnbed 
functions of microprocessor 26. 
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Figure 19 is a How diagram illustrating command process 382 of Figure 18 m greater 
detail beginning at 390. Initially, the host computer will establish a communication Imk w.th 
interface device 14 in step 391. THis can be accomplished by sending a predetermined s.gna^ or 
information which the interface device is waiting to receive. The interface device then can send an 
answer signal indicating it is ready to receive commands. If the USB communication mterface .s 
being used, the command process 382 preferably requests a USB address from the host, wh.ch 
the processor 382 then receives and stores. Whenever a data packet is then sent from the host, the 
command processor 384 can check the address of the data packet and compare it to the stored 
address to determine if the packet is meant for the microprocessor 26. 

In addition, if USB is being implemented, the command processor 384 can check for data 
in the USB communication protocol and reporting processor 387 can send out data m th.s 
protocol This protocol includes a token packet, followed by a data packet, which is followed by a 
handshake packet, as is well known to those skilled in the art. The host commands can be 
encrypted in the data packets. 

In next step 392, host computer 12 may require the characteristics of the interface device 
14 so that appropriate force feedback commands suited to the particular interface device can be 
provided by the host computer. These characteristics may include, for example, the senal 
number, model number, style, number of provided degrees of freedom of user object 34, 
calibration parameters, and reportmg rate of the interface device. Upon receiving a request for 
such information from the host computer 12. such as a "request information" command, the 
microprocessor 26 sends the information to the host computer 12 in step 392. The host computer 
would normally request these characterisucs only at power-up or at the start of foree feedback 
implementation. 

In next step 394. the microprocessor 26 receives conf.guralion commands from the ho.st 
computer 12 and sets appropriate reporting parameters. As mentioned above, the reportmg 
parameters may actermine whether such infomiation as sensor data, which includes sensor 
readings, values computed from sensor readmgs. and/or sensor "histories" (i.e., a number of 
previously recorded or computed sensor values), or clock time values are sent to the host 
computer 12 from the status update process 386. The sensor data may include sensor error data, 
histories of data describing which buttons have been pressed on the interface device, posu.ons. 
velocities, and/or accelerations of the user object, data from which degrees of freedom will be 
reported to the host computer, and whether data is reported to the host computer in a query or 
stream mode. These configuration options allow the programmer to set up wh.ch data the host 
computer will receive from the local microprocessor. For example, if an application requires user 
object position dau in only one of two provided degrees of freedom, then it is a waste of 
processing time for the microprocessor to be sending infonnation of the unused degree of 
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freedom to the host computer. The programmer can set reponing parameters with conFtguration 
commands to send only the ncccssar>' data to the host computer. 

In next step 396. the process checks if a host command has been received. If not, step 396 
loops continuously until a host command is received. Step 398 is then implemented, in wh.ch the 

5 process detennines whether the received command(s) is a configuration command. A 
configuration command sets the reporting parameters, as described above. If the command ts a 
configuration command, step 400 sets appropriate reporting parameters and/or resets the reporting 
parameters to provide a new configuration during the operation of the interface device. If step 398 
determines that the received command is not a configuration command, then step 398 has detected 

,0 a force command which controls force feedback functionality of the interface dev.ce 14. Force 
commands include those host commands that provide command parameters that affect the 
internal foree parameters (e.g.. the host commands shown in Figures 9 and 14). 

In step 402 the force commands and command parameters set force parameters, such as 
those related to implementing a particular force paradigm or model specified by the force 
15 command. Process 388 accesses these force parameters in memory to apply forces usmg 
actuators 30, as described with reference to Figure 22. As an example, the force command and 
force parameters may designate particular buttons on the interface device 14 and assign a jolt force 
model to each designated button. If a user then presses a designated button, the jolt ass.gned to 
the pressed button would in turn be activated using whatever force parameters arc currently .n 
20 memory. An example of force parameters is described below with reference to Figure 23. After 
setting the force parameters, step 402 then transfers control back to step 396 to wait to receive 
another host command. 

In addition, in the preferred embodiment, process 384 also is regularly checking/receiving 
for a "heartbeat" signal from host computer 12 after a predetermined time interval. Th.s signal 
25 would be a safety check to indicate that the host computer is sull connected to interface device 14 
and that the host has an "OK" status. If no heartbeat signal is received within the time interval, the 
interface device 14 can deactivate and wait for an initialization command from the host. The 
••heartbeat" signal can be a normal signal or host command, or it can be a signal specifically used 
as a heartbeat signal that the host computer can send if no other signals have been sent with.n the 
30 ume interval. After a signal has been received in step 396, process 384 preferably stores the time 
that the signal was received in a particular memory location. Process 388 can examine this time to 
determine if the interval has been exceeded (described below). 

Figure 20 is a fiow diagram illustrating status update process 386 of Figure 1 8, beginning 
at a step 410. In step 412. the process 386 examines reporting and fon:e parameters set by the 
command process 384. Preferably, process 386 examines the reporting and state parameters in 
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memory 17 which have been updated by command process 384. From both the reporting and 
force parameters, step 414 determines which sensors will be read. The force parameters 
determine which sensor data is necessary for the process 388 to compute a force. For example, if 
the force parameters determine that a force needs to be calculated about the x-axis and not the y- 
axis, then the sensor data from the y-axis sensors is not needed to computer forces. The reporting 
parameters determined which sensor data to report to the host computer. Thus, the reporting 
parameters may also specify that y-axis sensor data docs not have to be sent to the host computer, 
since the host computer is ignoring that particular data. Thus, since the y-axis dau is both not 
being used to compute a force and is not needed by host 12. the microprocessor 26 determines in 
step 414 not to read the y-axis sensors. 

Step 416 determines whether velocity and/or acceleration are always computed. The result 
of this step depends on the particular embodiment that is implemented. In some embodiments, it 
may be simpler and require less processing time if velocity and/or acceleration data are always 
computed, regardless of whether the velocity/acceleration data is needed to compute forces or to 
be sent to host 12. In other embodiments, the velocity/acceleration data can be computed only if 
such data is necessary to compute force values or if the host 12 requires these values. In yet other 
embodiments, the mode ("always compute" or "compute only when necessary") can be set 
depending on the particular application or other determining factor. 

In an embodiment that always computes velocity and acceleration, step 418 is 
implemented, in which the velocity and/or acceleration values are computed using sensor readings 
and timing data. For example, a history of recorded position values and associated time intervals 
can be used to calculate velocity. The process then continues to step 422. If such an embodiment 
is not being used, then step 420 coniputes the velocity and/or acceleration values only if 
appropriate. The process 386 can examine the force parameters and reporting parameters, 
similarly as in step 414, to determine if velocity and/or acceleration values should be computed. 

After step 418 or 420. step 422 is perfomied, in which the process 386 stores in memory 
27 the sensor data and timing data read from sensors 28. clock 29. and computed in step 418 or 
420. The sensor data and timing data may also include data pertaining to other input devices 39. 
e.g.. if a button has been pressed (sensor data) and how long a button on the interface device 14 
has been pressed (timing data) so that a button repeat or button hold ("autofire") feature may be 
activated at the proper time. As noted above, process 386 is preferably sharing the 
microprocessor's 26 processing time since multiple processes are running in parallel (multi- 
tasking). In this case, the process 386 may need to wait at step 424 until the microprocessor 26 is 
available or to purposely allow another waiting process to use microprocessor 26. In addition, the 
waiting step may be necessary to write output data to memory 27 at a consistent or slower time to 
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allow force compuUtion process 388 greau:r flexibility in reading the output data from the 
memory. 

Figure 21 is a flow diagram illustrating reporting process 387 of Figure 18 to report data 
to the host computer, beginning at a step 430. Step 432 determines whether reporting is done m 
query or stream mode as specified by the reporting parameters set by command process 384. In 
this discussion, query mode uses an asynchronous reporting method based on requests for 
infonnation from the host computer, and stream mode uses a synchronous reporting method 
based on predetermined time intervals. 

In query reporting mode, step 434 detennines whether a request for a report has been 
received from host computer 12. The request can be received directly by reporting process 387. 
or alternatively, the request can be relayed to reporting process 387 through command process 
384 When the request is received, step 436 reports (i.e., sends out) sensor data and timmg data 
stored in step 422 in Figure 20 and error infonnation and force values from process 388 to the 
host The particular dau sent out depends on the reporting parameters specified by the 
configuration commands and the request received from the host. For example, >n some 
embodiments, the host 12 may be able to request particular infonnation. The process then returns 
to step 432 to detemtine if query or stream mode is being used. Thus, in the descnbed 
embodiment, modes can be switched at any time during data transmission. In alternate 
embodiments, one particular reporting mode may be the only option available. Ahemat.vely. both 
modes may be available, but once one mode is selected at the beginning of the operation of 
interface device 14. thai mode may not be switched. 

In stream reporting mode, step 438 detennines whether the reporting lime period has 
expired. Preferably, a standard reporting time period is se. when the interface device and host 
computer 12 are first set up. When the time period has expired, step 440 reports data siored in 
step 422 in Figure 20 in accordance with the reporting parameters. If time has not expired, the 
process returns to step 432 to again detemiine the reporting mode. 

Figure 22 is a flow diagram illustrating force algorithm compuution and acniator control 
process 388 of Figure 18 beginning at a step 450. Preferably, all forces in each degree of freedom 
are initialized to zero before step 450 at power up or upon receipt of a clear command from the 
hostcomputer 12. Thereafter, process 388 would begin at 450 and proceed with step 452. Instep 
452 an axis or degree of freedom for which a force is to be applied is selected. Herein, • ax.s" ts 
synonvmous with a degree of freedom provided by the interface device 14. If two axes require 
forces'to be applied, an axis that has not had a force applied in the cunent iteration is preferably 
selected in step 452. For example, if forces are required about the x and y axes, and if the fon:e on 
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the X axis was just computed and applied in the previous iteration of the loop, then the y-axis is 
preferably selected. In addition, a total force in the selected axis is initialized to zero in step 452. 

Step 456 computes a force in the selected axis according to the next reflex process selected 
in accordance with the force parameters. This step preferably includes selecting an appropriate 
reflex process, retrieving the necessary sensor data, timing data, and other data, and computing a 
force value using the selected reflex process and retrieved data. The reflex process is selected by 
examining the force parameters. The current values of the force parameters reflect the host 
commands that are currently in effect. Since multiple host commands (reflex processes) may 
simultaneously be in effect, the force parameters are examined by process 388 to detennine one of 
the reflex processes to execute to compute a force. Thus, process 388 can examine the force 
parameters to determine which commands were sent by host computer, and determine which 
reflex process to execute in accordance with those commands. As described above with reference 
to Figure 5. the reflex process can include process steps, equations, force proflles, or other 
combinations of instructions to compute a force from sensor data, timing data, command 
parameters, other input data from input devices 39, and/or other related information. The 
command parameters are reflected in the force parameter values. Process 388 thus retrieves the 
necessary sensor data, timing data, force parameters and/or other data required by the selected 
reflex process to compute a force value. 

In step 458. process 388 adds the force value computed in step 456 to the total force for 
the axis initialized in step 452. In alternate embodiments, process 388 may limit the total force 
value or a portion of the total force value computed in step 458. For example, if process 388 is 
keeping track of which force values arc condition forces and which force values are overiay 
forces, the process 388 can limit the sum total of condition forces to a predetermined percentage 
of maximum actuator force output, such as 70% of maximum output. This allows some of the 
available force range to be used for overlay forces, such as button jolts, vibrations, etc. that may 
applied on top of the condition forces. This limiting is preferably performed after all condition 
forces that are in effect have been computed, so that overlay forces can be applied over the sum of 
all condition forces. Other forces can be limited in alternate embodiments. 

In next step 460. process 388 determines if another reflex process needs to be executed for 
the currently selected axis. This would be true if additional host commands are in effect for which 
forces have not yet been computed and added to the total force. If so, the process renims to step 
456 to check the force parameters, execute another reflex process to compute a force, and add that 
force to the total force. If, in step 460. there are no more reflex processes to be executed for the 
selected axis, then total force represents all forces in effect on the selected axis. Total force for the 
selected axis is then stored in memory 27 in step 462. 
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In siep 464. process 388 determines whether another axis (degree of freedom) needs to 
have a total force value computed. If so. steps 452. 456, 458. 460, and 462 are repeated for other 
axes until the total forces for the other axes are computed and stored. 

If step 464 determines that there are no more axes (degrees of freedom) for which forces 
rieed to be computed, step 466 may limit the total force on each axis. Since the total force on an 
axis computed above may exceed hardware specifications of the interface device, such as actuator 
force output, step 466 sets the total force to lie within the hardware's design range. Step 466 also 
may modify the total forte computed above when it may be unsafe to the user as indicated by an 
error flag. For instance, in the preferred embodiment, an error flag may be set if a safety 
condition is violated, as described in steps 468-472 below. This causes the output force to be 
zero In the preferred embodiment, the process 388 applies a smoothly increasing force to user 
object 34 after such a safety condition, since an abrupt jump in force output at the level before the 
safety condition might be dangerous for the user. In step 466. the process 388 can check how 
long ago the error flag was set by examining error timing infom^ation. and can limit the total force 
in accordance with a smooth ramp function of increasing force. 

Next step 468 applies safety conditions to the total force on each axis resulting from step 
466 Safety conditions may be violated when, for example, safety switch 41 as shown in Figure 1 
is activated, or when a specific command is sent by the host computer 12. When the safety 
conditions are violated, forces on the acmators 30 are sent to zero in step 470. The error flag .s 
then set in step 472 indicating the violation and timing information is wnnen as to when the error 
occurred. Process 388 then waits in step 474 until the microprocessor 26 is once again ready to 
proceed, similar to step 424 of Figure 20. 

As an additional safety feature, process 388 preferably examines memory 27 to determine 
if the host s "heartbeat" signal has been received within the required time interval. If process 388 
determines that the last signal was received outside of the allowed interval, then process 388 
assumes that the host has been disconnected or has had an error. All power to actuators 30 is thus 
turned off as a safety measure until an appropriate initializing command is received from the host. 

If the safety conditions are not violated in step 468. the total force for each axis is signaled 
to the appropriate actuators 30 to apply corresponding forces on those axes of the user object 34. 
In addition, process 388 can send any error information and any force values that have been 
output to reporting process 387. which determines whether to send the data to the host as 
described above (error information is sent to process 387 regardless of safety conditions). 
Preferably, process 388 writes this information to memory where reporting processor 387 may 
retrieve it. Subsequently, process 388 waits at step 474 until the microprocessor 26 is ready. 
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After step 474. the process returns to step 452 to select another axis in a new iteration of force 
computation and application. 

An illustrative application of the implementation 380 is now described with reference to 
Figure 23. In this example, a sluggish force will be applied to the user object 34 by the host 
5 computer 12 sending a SLUGGISH host command. A restoring spring force using a SPRING 
host command will then be commanded. Both the sluggish and restoring spring force models 
were discussed above under rate control paradigms and are listed in Figure 9. 

The force parameters 480 and 482 in Figure 23 represent locations in memory 27 used to 
store the force parameters for the SLUGGISH and SPRING commands. Preferably, a set of 
locations is similarly allocated to store force parameters for each command implemented by the 
microprocessor 26. The force parameters resulting from each host command 484 sent by the host 
computer 12 is shown. The locations of the sluggish force parameters are labeled by damping 
coefficients (B) for velocity components in positive and negative X and Y directions. Similariy. 
the spring table locations are labeled by spring coefficients (K) in the positive and negative X and 
Y axes and deadband sizes in the X and Y axes. 

Three host commands 484 are illustrated sequentially in Figure 23: 

SLUGGISH(50, X bi) 

SLUGGISH(90. X(+) uni) 

SPRING(65, X bi, 85) 

20 The two SLUGGISH command parameters 308 are the damping coefficient and style. The 
coefficient is a percentage of a maximum damping coefficient: 50% and 90%. The style 
command parameter in the first SLUGGISH command indicates a bi-directional force on the X 
axis. The style parameter in the second SLUGGISH command indirites a uni-directional force on 
the X axis in the positive direction on that axis. 

The three SPRING force feedback parameters are spring coefficient, style, and deadband. 
The spring coefficient parameter indicates 65% of a maximum spring coefficient. The style 
parameter indicates that the force is bi-directional in the X axis. The deadband is 85% of a 
maximum deadband size. 

A duration command parameter can also be included for each of the host commands 484, 
as shown in Figure 9. to provide the length of time that the command will be in effect. In the 
present example, however, the commands are assunied to be of infinite duration, and thus no 
duration command parameter is shown. The commands can be cancelled, for example, by a clear 
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command from the host. Aliematively. as shown, the commands can be cancelled or changed by 
another command of the same type. 

After the requested interface device information is sent to the host 12 in step 392 in Figure 
19, the host communication and background process 382 receives configuration commands in 
either step 394 or step 398. These configuration commands cause appropriate reporting 
parameters to be set. These reporting parameters can be implemented, for example, as flags 
corresponding to each allowed degree of freedom, other input device 39. position/velocity, 
query/stream mode. etc. to indicate whether to report data from those devices to the host (and to 
select modes, when appropriate). For maximum efficiency, the reporting parameters would only 
have nags set for the X axis, since Y-axis data is not necessary. However, the Y-axis sensor data 
might be needed by host computer for other reasons, and thus still might have flags set and thus 
be reported to the host. 

Thereafter, the force parameters 480 and 482 arc set in step 402 of Figure 19 based on the 
SLUGGISH and SPRING host commands and the command parameters they include, as shown 
in Figure 23. TTie command SLUGGISH(50. X bi) causes step 402 to write "SO" in the force 
parameter locations 486 conesponding to x-axis coefficients Bx(+) and Bx(-). Ml the rcmammg 
locations of all the other force parameters are zero, since it is assumed that the first sluggish 
command is the first command received by interface device 1 4 after power up. 

The other processes 386 and 388 examine the force parameters 480 and 482 (as well as 
20 other force parameters for other reflex processes) and are implemented as shown in Figures 20 ad 
22. Thus, when state update process 386 determines which sensors to be read in step 414 of 
Figure 20. it examines the force parameters 480 and 482 to detennine which commands are in 
effect. Since all of the restoring force parameters 482 for the restoring spring force are zero, a 
restoring spnng command is not in effect (processes 386 and 388 only actually need to look at a 

25 subset of the force parameters to determine if the command is in effect). However, force 
parameters 480 include two values ("50"), and thus is in effect. Thus, only the x-axis sensors 
need to be read (assuming the host does not need y-axis information, as indicated by the reporting 
parameters). In step 420 (if implemented), process 386 would calculate velocity from the sensor 
readings (and/or a history of sensor readings) and timing data, since the sluggish command 

30 requires a velocity value to compute a force (accelerations are irrelevant in the present example). 

Process 388 would check force parameters 480 and 482 in step 456 of Figure 22. The X 
axis is the only relevant axis to select in step 452. Since force parameters 482 are all zero, process 
388 knows not to execute a restoring spring rcfiex process. Since force parameters 480 do 
include non-zero values, a sluggish reflex process should be executed. In one example, the reflex 
35 process would include the equation F = BV. where B is the coefficient stored at locations 486a 
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and 486b. and V is the velocity calculated by state update process 386. F is the total force that 
would be output by actuators 30 about the axis. Preferably, all the available host commands have 
force parameters that processes 386 and 388 would similarly check to detennine which 
commands are in effect. 

Referring back to Figure 23. the second command SLUGGISH (90, X+ UNI) is sent by 
host computer 12 after the first sluggish command. Since the second SLUGGISH command is 
uni-directional in the positive x-axis. only the first location 486a for the Bx(+) force parameter 
has the new coefficient "90" written over the previous value. The restoring spring force 
parameters are unchanged by the SLUGGISH commands. One way to cancel the first 
SLUGGISH command would be to send a second SLUGGISH command having all command 
parameters equal zero. 

The status update process 386 would operate similarly for the second SLUGGISH 
command as for the first SLUGGISH command. The force algorithm computation and actuator 
control process 388 would operate similarly as well, except that the sluggish reflex process 
selected in step 456 of Figure 22 would compute a different sluggish force for velocities in the 
positive X direction (based on a coefficient of 90) than in the negative x direction (based on a 
coefficient of 50). The process 388 would use the sensor information from status update process 
386 to determine which direction the user was moving the user object and use the appropriate 
coefficient. 

Referring back to Figure 23, the third command sent by host 1 2 is the SPRING command 
SPRING (65 X BI 85). Step 402 of Figure 19 thus changes the restoring spnng force 
parameters 482 by writing 65 for Kx(+) and Kx(-) and 85 for DBx- The SLUGGISH force 
parameters are unaffected by the SPRING command and thu.s remain in effect with the previous 
values. Process 388 would execute the sluggish reflex process and compute a force, then execute 
the restoring spring reflex process and compute a force. The restoring spring reflex process could 
be. for example, implemented by the equation F = kx, where k is the spring constant and x is the 
, position of the user object with respect to the origin position. The two forces from sluggish and 
spring reflex processes would be added together at step 458. Therefore, the sluggish and restoring 
spring force models are superimposed on the user object 34 after the SPRING command in 
Figure 23. This would create a viscous feel on the user object 34 and simultaneously apply force 
toward the origin position of the user object. 

More generally, for other command sequences not shown in Figure 23, any number of 
force models may be superimposed. For example, two forces could be superposed if the first 
SLUGGISH command were immediately followed by the SPRING command. 
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Alternatively, the three commands shown in Figure 23 can be received by microprocessor 
26 and all the force parameters shown after the SPRING command can be stored as a parameter 
page in memory to form a "force environment." When this force environment was desired to be 
applied to user object 34. the page of force parameters and reporting parameters would be 
retneved and processed by processes 386 and 388. This can be useful when many different 
commands are desired to be applied simultaneously: The microprocessor would not apply each 
host command as it was received, but would load all the desired force parameters for a force 
environment at once from memor>'. 

While this invention has been described in terms of several preferred embodiments, it is 
contemplated that alterations. modiHcations and permutations thereof w.H become apparent to 
those skilled in the art upon a reading of the specification and study of the drawmgs. For 
example, many possible types of actuators and sensors can be used .n the present mventton. 
Also, many types of mechanisms can be included to provide one or more degrees of freedom o 
object 34. m addition, different types of interfaces can be used to connect the host computer to the 
local microprocessor. A wide variety and types of forces can be transmitted to a user object by 
the present invention. Many different types of force models can be implemented m many dist.nct 
processes running on the microprocessor, only some of which are described herein. In addition 
the application of reflex processes on a local microprocessor can be implemented in a vanety of 
ways. Furthermore, certain terminology has been used for the purposes of descriptive clanty and 
not to limit the present invention. It is therefore intended that the following appended claims 
include all such alterations, modifications and permutations as fall within the true sp.nt and scope 
of the present invention. 
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AIMS 



1. A system for controlling an electromechanical interface apparatus manipulated by a 
user, the system comprising: 

a host computer system for receiving an input conu-ol signal and for providing a host 
command having at least one command parameter to control forces on a user manipulable object 
of said interface apparatus, wherein said host computer system updates a process in response to 
said input control signal; 

a microprocessor positioned local to said interface apparatus and separate from said host 
computer system for receiving said host command from said host computer system and 
providing a processor output control signal in accordance with said at least one command 
parameter; 

an actuator for receiving said microprocessor output control signal and providing a force 
along a degree of freedom to said user manipulable object in accordance with said microprocessor 
15 output control signal, said object being coupled to said acniator and being graspable and movable 
by said user; and 

a sensor for detecting moiion of said manipulable object along said degree of freedom and 
outputiing said input control signal includmg information representative of the position and 
moiion of said object. 

20 

2. A system as recited in claim 1 wherein said sensor outputs said input control 
signal to said microprocessor, and wherein said microprocessor provides said input control signal 
to said host computer system. 

3. A system as recited in claim 2 wherein said microprocessor implements one of a 
25 plurality of reflex processes selected in accordance with said host command and said command 

parameters to provide said microprocessor output control signal to said actuator in response to 
said position and motion of said object independently of said host command. 

4. A system as recited in claim 3 wherein a magnitude of said force output by said 
acniator is determined by a force value output in said microprocessor output control signal, said 
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force value being detennined by said selected reflex process based on said at least one command 
parameter included in said host command. 

5. A system as recited in claim 4 wherein a direction along said degree of freedom of 
said force output by said actuator is determined by an indicauon of a direction in said 
microprocessor output control signal, said direction being detennined by said selected reflex 
process according to said at least one command parameter included in said host command. 

6. A system as recited in claim 5 wherein said at least one command parameter 
includes a magnitude parameter determining a magnitude of said force to be output by said 
actuator. 

7. A system as recited in claim 5 wherein said at least one command parameter 
includes a duration parameter detemiining how long said force output by said actuator is in effect. 

8. A system as recited in claim 5 wherein said at least one command parameter 
includes a direction parameter detemiining the direction and degrees of freedom of said force 
output by said actuator. 

9. A system as recited in claim 5 wherein said at least one command parameter 
includes button parameters which designate a button coupled to said microprocessor and 
determine a magnitude, direction, and duration of a force output by said actuators when said 
button is pressed by said user. 

10. A system as recited in claim 4 wherein said hosi computer system displays images 
on a visual output device and manipulates said images in accordance with a position and a motion 
of said object. 

11. A system as recited in claim 10 wherein said displayed images include a computer 
object in a computer environment directly mapped to a position of said user object, and wherein 
said host command is a position control command operative to cause forces to be output directly 
in accordance with the location of said computer object and said user object. 

12. A system as recited in claim 1 0 wherein said displayed images include a computer 
object in a computer environment, wherein a motion of said computer object is directly mapped to 
a position of said user object, and wherein said host command is a rate control command 
operative to cause forces to be output directly in accordance with a position of said user object in 
said degree of freedom and in accordance with a computer environment of said computer object. 

13. A system as recited in claim 10 wherein said displayed images include a computer 
object in a computer environment under control of said user, and wherein said displayed images 
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10 



include a computer object under control of said user, and wherein said host command provides 
local position control to cause output forces to be output in accordance with a location of said 
computer object and said user object, and provides global rate control to cause output forces to be 
output in accordance with said computer environment and said user object. 

14. A system as recited in claim 1 wherein said host computer and said 
microprocessor are coupled together by a serial interface. 

15. A system as recited in claim 14 wherein said serial interface includes a Universal 
Serial Bus interface. 

16. A system as recited in claim 3 wherein said microprocessor and said acmator are 
including in a single housing and are coupled to said host computer by a communication interface. 



17. A method for interfacing a force feedback interface device manipulated by a user 
with a host computer system, the method comprising the steps of: 

providing a user manipulable object included in said force feedback interface device, said 
15 object having a degree of freedom; 

sensing positions of said objecl along said degree of freedom with a sensor and producing 
electrical sensor signals therefrom; 

utilizing a microprocessor local to said object to communicate with said host computer 
system to provide said electrical sensor signals to said host computer system and to receive a host 
20 command from said host computer system, said host command including a command parameter; 
and 

creating a force on said object along said degree of freedom independently utilizmg said 
microprocessor and said host command to control an actuator coupled to said object. 



25 18. A method as recited in claim 17 wherein said step of creating a force on said user 

manipulable object includes the steps of: 

selecting a reflex process by said microprocessor in accordance with said host command; 

outputting microprocessor force commands from said microprocessor to said actuator 
utilizing said reflex process and said electrical sensor signals. 
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19. A method as recited in claim 18 wherein said command parameter is a magnitude 
parameter for controlling a magnitude of said force output by said actuator. 

20 A method as recited in claim 19 wherein said command parameter is a duration 
5 parameter for controlling the time duration of said force applied to said user manipulable object. 

21 A method as recited in claim 19 wherein said command parameter is a direction 
parameter for controlling the direction of said force along a degree of freedom output by sa,d 

actuator. 

22. A method as recited in claim 19 wherein said command parameter indicates a degree 
10 of freedom of said user object in which to apply said force. 

23 A method as recited in claim 19 wherein said command parameter is a deadband 
parameter for indicating the size of a deadband region about an origin position of said user object, 
wherein said force is not applies to said user object in said deadband region. 

24 A method as recited in claim 19 wherein said command parameter mcludcs a button 
,5 parameter instructing said microprocessor to read input from a designated button and generate a 

force in response to said designated button being activated by said user. 

25 A method as recited in claim 18 wherein said host command .s a position control 
command which instructs said microprocessor to control said force output by .said actuator b.sed 
on a position of a computer object on a display screen, said computer object being comrolled by 

20 said user manipulable object. 

26 A method as recited in claim 18 wherein said host command is a rate control 
command which instructs said microprocessor to control said force output by said acniator based 
on a velocity of a computer object provided by said host computer and a pos.t..n of said user 
manipulable object. 

27. A method as recited in claim 18 wherein said user manipulable object includes a 
joystick that can be moved by said user in two degrees of freedom. 

28. A method as recited in claim 27 wherein said two degrees of freedom are rotary 
degrees of freedom. 



25 
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30. A method as recited in claim 27 further comprising a step of updating game or 
simulation software implemented by said host computer system in accordance with said position 
signals. 

31. A method as recited in claim 18 wherein said selected reflex process retrieves a 
5 plurality of stored digital force values and outputs said stored force values to said actuator. 

32. A method as incited in claim 18 further comprising a step of using calibration 
parameters stored in a memory device for adjusting said force consistently with output forces of a 
plurality of other force feedback interface devices having variations in physical properties resulting 
from a manufacturing process. 

10 33. A method as recited in claim 17 wherein said microprocessor communicates with 

said host computer using a serial interface. 

34. A method as recited in claim 33 wherein said serial interface includes a Universal 
Serial Bus. 

35. A method as recited in claim 17 further comprising a step of utilizing said 
15 microprocessor to record a history of sensor values read from said sensor. 

36. A method as recited in claim 34 wherein time data is retrieved from said Universal 
Serial Bus interface which is used to determine, in pan. said force output on said user object. 

37. A method as recited in claim 34 wherein a power signal is retrieved from said 
Universal Serial Bus interface which is used to power said actuator to output said force. 

20 

38. A force feedback interface device manipulated by a user and communicating with a 
host computer system implementing a host application program, said host computer system 
updating said host application program in response to input signals, said force feedback interface 
device comprising: 

25 a microprocessor, separate from said host computer system, for communicating with said 

host computer system via a communication bus by receiving a host command from said host 
computer system and implementing said command in a reflex process, and by relaying said input 
signals to said host computer system; 

a user object movable in a degree of freedom by a user and being physically contacted by 
30 said user; 
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an actuator electrically coupled to said microprocessor for applying a force along a degree 
of freedom to said user object in accordance with a microprocessor force command from said 
microprocessor, said microprocessor force command being derived from said host command, 
said reflex process, and a position of said user object; and 

a sensor electrically coupled to said microprocessor for detecting a position of said user 
object along said degree of freedom and outputting said input signals to said microprocessor, said 
input signals including information representative of said position of said user object. 

39 A force feedback interface device as recited in claim 38 wherein said host 
command instructs said microprocessor to select one of a plurality of reflex processes available to 
said microprocessor, wherein each of sa.d reflex processes mstruc.s said microprocessor to output 
foree commands to said actuator and process said input signals from said sensor independemly of 
said host computer system. 

40 A force feedback interface device as recited in claim 38 wherein said 
microprocessor calculates velocity or acceleration values from said input signals from sa,d sensor. 

41 A force feedback interface device as recited in claim 39 further comprising a clock 
provided locally to said microprocessor used to provide timing dau used in the calculation of 
velocity and acceleration values from said input signals of said sensor. 

42 A force feedback interface device as recited in claim 39 wherein said host 
command instructs said microprocessor to select a restoring foree refiex process to provide 
restoring forces on said user object in a direction toward an origin position of sa.d user object. 

43 A force feedback interface device as recited in claim 42 wherein said restoring 
forees are constant in magnitude when said user object is positioned outside a region near an 
origin position of said user object, and wherein said restoring forces are near to zero within said 
region near said 'origin position. 

44 A foree feedback interface device as recited in claim 39 wherein said host 
command instructs said microprocessor to select a vibration refiex process to provide vibration 
forces on said user object. 

45 A force feedback interface device as recited in claim 44 wherein said host 
command includes command parameters to control a frequency and a magnitude of said vibration 
forces. 
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46. A force feedback interface device as recited in claim 39 wherein sa.d host 
command instructs said microprocessor to select a texture reflex process to provide texture forces 
on said user object, said texture forces being mapped to a position along said degree of freedom. 

47. A force feedback interface device as recited in claim 46 wherein said host 
command includes a command parameter specifying a spatial density of said texture forces along 
said degree of freedom. 

48. A force feedback interface device as recited in claim 39 wherein said host 
command instmcts said microprocessor to select a barrier reflex process to provide a barrier force 
on said user object based on the position of said user object. 

49. A force feedback interface device as recited in claim 48 wherein said barrier force 
is removed after said user object is moved a snap distance past said barrier force. 

50. A force feedback interface device as recited in claim 49 wherein a location of said 
barrier force along said degree of freedom is specified by a command parameter included in said 
host command. 

51. A force feedback interface device as recited in claim 48 wherein said barrier force 
simulates a virtual obstruction, such that when a computer controlled object moves into said 
virtual obstruction m said host application, said barrier forces are output according to said barrier 
reflex process. 

52. A force feedback interface device as recited in claim 39 wherein said host 
command instructs said microprocessor to select a force field reflex process to provide attractive 
or repulsive forces on said user object depending on said position of said object. 

53. A force feedback interface device as recited in claim 52 wherein a location of a 
Held ongin position determines at what positions of said user object said forces are applied, said 
origin location being specified in a command parameter included with said host command. 

54. A force feedback interface device as recited in claim 39 wherein said host 
command instmcts said microprocessor to select a jolt reflex process to provide a jolting force on 
said user object for a limited duration. 

55. A force feedback interface device as recited in claim 39 wherein said host 
command instructs said microprocessor to select a damping reflex process to provide damping 
forces on said user object, said damping force being dependent on a velocity of said user object. 
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56. A force feedback interface device as recited in claim 55 wherein a command 
parameter included with said host command specifies whether said damping force is applied bi- 
directionally or uni-directionally along said degree of freedom. 

57. A force feedback interface device as recited in claim 39 wherein said host 
5 command instructs said microprocessor to select a groove reflex process which instructs said 

microprocessor to provide forces on said user object to simulate a physical groove. 

58. A force feedback interface device as recited in claim 57 wherein a command 
parameter included with said host command specifies an orientation of said groove. 

59. A force feedback interface device as recited in claim 57 wherein a command 
10 parameter included with said host command includes a snap distance for said groove, such that 

when said user object exceeds said snap distance, said forces of said groove are removed. 

60. A force feedback interface device as recited in claim 39 wherein said host 
command instructs said microprocessor to select a paddle reflex process which instructs said 
microprocessor to provide forces on said user object in accordance with a user controlled paddle 

15 displayed by said host computer system, said paddle compressing from contact with other 
displayed objects and movable by said user to provide force on said other displayed objects. 

61. A force feedback interface device as recited in claim 60 wherein said host 
command includes a command parameter controlling a simulated compliance of said simulated 
paddle. 

20 62. A force feedback interface device as recited in claim 60 wherein said 

microprocessor calculates said forces in accordance with said paddle and said other displayed 
objects, wherein said microprocessor reports positions of said paddle and said other displayed 
objects to said host computer periodically. 



25 63. A computer readable medium including program insimctions for providing force 

feedback to a user-manipulable object of an interface device and for communicating with a host 
computer system implementing a host application program, said program instructions performing 
steps comprising: 

receiving a host command on a microprocessor local to said interface device and separate 
30 from said host computer system; 
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processing said host command and storing force parameters derived from said host 
command: 

receiving sensor data from sensors describing a motion of said user object of said interface 

device; 

5 computing a force value using a reflex process selected in accordance with said force 

parameters and said sensor data: and 

outputting a force on said user object utilizing actuators coupled to said user object, said 
force corresponding to said force value.. 

64. A computer readable medium as recited in claim 63 wherein said host command 
10 includes at least one command parameter, and wherein said force parameters arc derived from 

said host command and said at least one command parameter. 

65. A computer readable medium as recited in claim 64 wherein said step of storing said 
force parameters includes providing a set of force parameter memory locations for each host 
command which can be sent by said host computer, and writing said force parameters for said 

15 received host command in said force parameter memory locations that correspond to said received 
host command. 

66. A computer readable medium as recited in claim 64 wherein said sensor data includes 
position data describing a position of said user object in a provided degree of freedom. 

67. A computer readable medium as recited in claim 66 further comprising a step of 
20 determining velocity values from said position data. 

68. A computer readable medium as recited in claim 67 wherein said step of receiving 
sensor data includes receiving velocity data from said sensors, said sensors being velocity 
sensors. 

69. A computer readable medium as recited in claim 64 wherein said force value is 
25 dependent on said sensor data. 

70. A computer readable medium as recited in claim 64 wherein said force value is 
dependent on said at least one command parameter. 

71. A computer readable medium as recited in claim 64 wherein said force value is 
dependent on input from a button provided on said interface device. 
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72 A computer readable medium as recited in claim 69 funhcr comprising a step of 
reading timing data from a dock and using said timing data to calculate said force value. 

73 A computer readable medium as recited in claim 69 wherein said step of computing a 
force value is performed for each provided degree of freedom of said user object. 

5 74 A computer readable medium as recited in claim 73 wherein said step of computing a 

force value is performed for a plurality of host commands that are simultaneously in effect, and 
wherein a total force value is computed by adding said force values from each of sa,d host 
commands in effect. 

75. A computer readable medium as recited in claim 63 further comprising a step of 
10 reporting said sensor data to said host computer system. 

76. A computer readable medium as recited in claim 75 wherein only sensor data required 
by said host computer system is reported to said host computer system. 

77 A computer readable medium as recited in claim 76 wherein said host command is a 
configuration command which determines which sensor data is reported to said host computer. 

,5 78 A computer readable med.um as recited in claim 76 wherein said host command is 

a configuration command which determines a rate at which sensor dau is to be reported to sa.d 
host computer. 

79. A computer readable medium as recited in claim 63 further comprising a step of 
checking for a violation of a safety condition before outputting said force. 

20 80 A computer readable medium as recited m cla.m 79 further comprising a step of 

removing all output force when said violation occurs, and wherein when said safety condition is 
no longer violated, said force is gradually reapplied to said user object over time. 

81 A computer readable medium as recited in claim 63 wherein a plurality of said 
received host commands are stored as said force parameters in memory as a force environment. 

25 said force environment being retrievable when forces a« to be output on said user object m 
accordance with said plurality of received host commands. 

82 A computer readable medium as recited in claim 79 further comprising a step of 
creating one of said force environments using incoming host commands while a different, 
previously-created force environment is used to apply said force to sa.d user object. 
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83 A computer readable medium as recited in claim 64 wherein said step of computing a 
force value includes limiting said force value so that other forces may be overlaid on said output 
force. 



84. A processing apparatus coupled to an interface device that provides force feedback to 
a user-manipulable object coupled to said interface device and which communicates with a 
separate host computer system, said processing apparatus comprising: 

a command processor for receiving a host command from a separate host computer 
system, said host command including a command parameter, and for processing said host 
command and storing force parameters derived from said host command and said command 
parameter; 

a status update processor for receiving sensor data from sensors describing a motion of 
said user object of said interface device; and 

a force output processor for computing a force value using a reflex process selected in 
accordance with said force parameters and said sensor data, said force output processor outputting 
a force on said user object utilizing actuators coupled to said user object, said force corresponding 
to said force value. 



85. A processing apparatus as recited in claim 84 wherein a set of force parameter 
locations for each host command which can be sent by said host computer are stored in a memory 
device, and wherein said force parameters for said received host command are written in said 
force parameter locations corresponding to said received host command. 

86. A processing apparatus as recited in claim 84 wherein said force value is dependent 
on said sensor data and said command parameter. 

87. A processing apparatus as recited in claim 84 further comprising a reporting 
processor for reporting said sensor data to said host computer system. 

88. A processing apparatus as recited in claim 86 wherein said reporting processor only 
reports sensor data required by said host computer system. 

89. A processing apparatus as recited in claim 84 wherein said force output processor 
selects a reflex process for a plurality of host commands. 
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90. A processing apparatus as recited in claim 84 wherein said status update processor 
receives input data from a button provided on said interface device. 

91. A system for controlling an electromechanical interface apparatus manipulated by a 
user, the system comprising: 

a host computer system for receiving an input control signal and for providing a host 
output control signal, wherein said host computer system updates a process in response to said 
input control signal; 

a microprocessor local to said interface apparatus and separate from said host computer 
system for receiving said host output control signal from said host computer system and 
providing a processor output control signal; 

an actuator for receiving said processor output control signal and providing a force along a 
degree of freedom to a user manipulate object coupled to said actuator in accordance with said 
processor output control signal; 

a sensor for detecting motion of said manipulable object along said degree of freedom and 
outputting said input control signal including information representative of the position and 
motion of said object. 

92. A system as recited in claim 91 further comprising a clock coupled to said host 
computer system, wherein said clock is accessed to determine, at least in part, said force provided 
by said actuator; and 

93. A system as recited in claim 92 wherein said sensor outputs said input control signal 
to said microprocessor, and wherein said microprocessor provides said input control signal to said 
host computer. 

94. A system as recited in claim 92 wherein said host output control signal output by said 
host computer is a force command that is relayed directly to said actuator by said microprocessor. 

95. A system as recited in claim 93 wherein said microprocessor is operative in a reflex 
process to provide said microprocessor output control signal to said actuator in response to said 
position and motion of said object independently of said host output control signal. 

96. A system as recited in claim 95 wherein said host output signal is a high level 
command from said host computer system, and wherein said microprocessor implements one of 
a plurality of local processes selected in accordance with said high level command to implement 
said reflex process. 
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97. A system as recited in claim 96 wherein said host computer can override said reflex 
process such that said host output signal includes a force command that is relayed directly to said 
actuator by said microprocessor. 

98. A system as recited in claim 93 wherein said object is grasped and moved by said 



5 user. 



99. A system as recited in claim 98 wherein said object includes a joystick. 

100. A system as recited in claim 99 wherein said joystick can be moved by said user in a 
plurality of degrees of freedom, and wherein said system further comprises an actuator for 
providing a force along a degree of freedom of said object, and a sensor for detecting motion of 

10 said object in said degree of freedom for each of said plurality of degrees of freedom. 

101. A system as recited in claim 97 further comprising a serial interface for outputting 
said host output control signal from said host computer system and for receiving said input 
control signal to said host computer system 

102. A system as recited in claim 93 further comprising a parallel interface for outputting 
15 said host output control signal from said host computer system and for receiving said input 

control signal to said host computer system. 

103. A system as recited in claim 101 further comprising an additional interface for 
providing said input signal to said host computer system through a game port of said host 
computer system. 

20 104. A system as recited in claim 93 wherein said actuator is a servo motor or a voice 

coil. 

105. A system as recited in claim 93 wherein said process updated by said host computer 
system includes simulation software or game software. 

106. A system as recited in claim 105 wherein said host computer system includes a 
25 display device for displaying a view of a video game implemented by said game software to said 

user, wherein said user can interact with said video game by manipulating said object. 

107. A system as recited in claim 93 wherein said clock is coupled to said 
microprocessor, wherein said microprocessor accesses said clock to determine, at least in part, 
said force provided by said actuator. 
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108. A method for controlling a force feedback interface device manipulated by a user, the 
method comprising the steps of: 

outputting a high level host command from a host computer system to a microprocessor 
local to said force feedback interface device and separate from said host computer system, said 
high level host command instructing said processor to select one of a plurality of force sensation 
processes available to said microprocessor; 

inpuning a position signal to said microprocessor from a sensor included m said force 
feedback interface device, said position signal including information representative of the position 
and motion of an object of said interface device grasped by said user, wherein said position signal 
is read from said sensor by said microprocessor according to said force sensation process 
independently of said host computer system and is sent to said host computer system from said 
microprocessor; 

outputting a microprocessor force command from said microprocessor to an actuator, said 
microprocessor force command being output according to said force sensation process 
independently of said host computer system; 

providing a force from said actuator to said object grasped by said user, wherein a 
direction and a magnitude of said force is in accordance with said microprocessor force 
command; and 

109. A method as recited in claim 108 further comprising overriding, when appropriate, 
said force sensation process by outputting a high level host command from sad host computer 
system that includes a force command relayed directly to said actuator by said microprocessor. 

1 10. A method as recited in claim 109 wherein a high level host force command is output 
by said host computer system when a change in a type of said force on said object is required, 
said change being based on. at least in part, a software process implemented by said host 
computer system. 

1 1 1 . A method as recited in claim 1 10 wherein said change is additionally based on said 
electrical sensor signals and timing informauon provided by a clock coupled to said 
microprocessor. 

1 12. A method as recited in claim 1 1 1 wherein said type of said force includes one of the 
group consisting of spring force, damping force, and ineriia force. 

113. A method as recited in claim 109 further comprising a step of said host computer 
system outputting audio feedback to said user when an audio event occurs in a host application 
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program, said audio feedback being output in synchronization with said output of said force 
within a tolerance of about 30 milliseconds when said force is desired to correspond to said audio 
event. 

114. A method as recited in claim 1 13 wherein said onset of said audio feedback occurs 
5 within about 30 milliseconds of an onset of said corresponding force, and wherein said audio 

feedback has an amplitude in direct proportion to a magnitude of said force. 

1 15. A method as recited in claim 109 wherein said host computer system outputs visual 
images on a display screen according to visual events in a host application program, said visual 
events being synchronized with said output of said force within a tolerance of about 30 

10 milliseconds when said force is desired to correspond to said visual event. 

1 16. A method as recited in claim 109 wherein said object includes a joystick that can be 
moved by said user in at least two degrees of freedom. 

117. A method as recited in claim 109 further comprising a step of updating game or 
simulation software implemented by said host computer system in accordance with said position 

15 signal and displaying images on a visual output device and manipulating said images in 
accordance with said position signal. 

118. A method as recited in claim 1 17 wherein said host computer receives said position 
signal and outputs said host force command signal using a serial interface. 

1 19. A method as recited in claim 118 wherein said serial interface is a Universal Serial 
20 Bus (USB) interface. 

120. A method as recited in claim 109 wherein said force sensation process determines a 
magnitude of said force to be provided by said actuator. 

121. A method as recited in claim 120 wherein said magnitude of said force is 
determined, at least in part, from a position of said object along said degree of freedom. 

25 1 22. A method as recited in claim 120 wherein said magnitude of said force is 

determined, in part, from a position and a velocity of said object moving along said degree of 
freedom. 

123. A method as recited in claim 120 wherein said magnitude of said force is 
determined, in part, from an acceleration of said object along said degree of freedom. 
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124. A method as recited in claim 120 wherein said magnitude of said force is 
determined, in part, from a clock providing timing information for said force commands. 

125. A method as recited in claim 120 wherein said magnitude of said force is 
determined, in part, from input data provided by a button input device included in said force 
feedback interface device. 

126. A method as recited in claim 120 wherein said magnitude of said force is 
determined, in part, from a position signal input from a second force feedback interface device 
coupled to said host computer system and interacting with a host application program 
implemented by said host computer system. 

127. A method as recited in claim 118 further comprising a step of using calibration 
parameters stored in a memory device for adjusting said force consistently with output fort:es of a 
plurality of other force feedback interface devices having variations in physical properties resuhmg 
from a manufacturing process. 

128. A force feedback interface device manipulated by a user and communicating with a 
i host computer system implementing a host application program, said host computer system 

updating said host application program in response to input signals, said force feedback interface 
device comprising: 

a user object movable in a degree of freedom by a user and being physically contacted by 
said user; 

20 an actuator for applying a force along a degree of freedom to said user object in accordance 

with a force command from said host computer system, said force command being received by 
said force feedback interface device via a first serial interface; and 

a sensor for detecting a position of said user object along said degree of freedom and 
outputting said input signals to said host computer system via a second serial interface separate 
25 from said first serial interface and coupled to a game port of said host computer system, said input 
signals including infonnation representative of said position of said user object. 

129. A force feedback interface device as recited in claim 128 further comprising a 
microprocessor, separate from said host computer system, for communicating with said host 
computer system via said first and second serial interfaces by receiving said force command from 
30 said host computer system, wherein said actuator is coupled to said microprocessor for applying a 
force along a degree of freedom to said user object in accordance with a microprocessor force 
command from said microprocessor, said microprocessor force command being derived from 
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said host force command, and wherein said sensor is electrically coupled to said microprocessor, 
to output said input signals to said microprocessor, and wherein said microprocessor sends said 
input signals to said host computer system. 

130. A force feedback interface device as recited in claim 129 wherein said force 
5 command is a high level command instructing said microprocessor to select one of a plurality of 

force subroutines available to said microprocessor, wherein each of said force subroutines 
instructs said microprocessor to output force commands to said actuator and input position signals 
from said sensor independently of said host computer system. 

131 . A force feedback interface device as recited in claim 129 further comprising a gimbal 
10 mechanism coupled to said user object to provide said degree of freedom, wherein said gimbal 

mechanism includes a closed loop five member linkage. 

132. A force feedback interface device as recited in claim 129 further comprising a slotted 
yoke mechanism coupled to said joystick, said slotted yoke mechanism providing at least two 
degrees of freedom to said object. 

,5 133. A method for interfacing motion of an object with a host computer system, the 

method comprising the steps of: 

providing an object having a degree of freedom; 

sensing positions of said object along said degree of freedom with a sensor and producing 
electrical sensor signals therefrom; 

20 creating a force on said object along said degree of freedom by controlling an acmator 

coupled to said object, including retrieving a force profile including a plurality of stored digital 
force values from a memory device and outputting said retrieved force values to said actuator to 
output corresponding feces on said object. 

134. A method as recited in claim 133 wherein said step of creating a force on said object 
25 further includes utilizing a microprocessor separate from said host computer system to 

communicate with said host computer system to provide said electrical sensor signals to said host 
computer system, receive host force commands from said host computer system, and output 
force commands to said actuator. 

135. A method as recited in claim 134 wherein said microprocessor retrieves said force 
30 profile and outputs said retrieved force values to said actuator. 
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136. A method as recited in claim 133 wherein said host computer retrieves said plurality 
of stored digital force values and outputs said retrieved force values to said actuator. 

137. A method as recited in claim 133 wherein said stored digital force values arc output 
to said actuator based on timing information provided by a system clock. 

138. A method as recited in claim 133 wherein said stored digital force values are output 
to said actuator based on said electrical sensor signals. 
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